mbourmaud/sillage-workflow

Use automatically when a change raises module boundaries, dependency direction, architectural patterns, or pressure to add abstractions; choose the smallest structure that protects an observed change.

Use automatically when a project needs a codebase, architecture, dependency, security, legacy, or technical-debt audit; separate observed facts from risk hypotheses and leave a ranked, bounded remediation path.

Use automatically when an approved Sillage slice is ready for implementation, coding, refactoring, migration, or a focused test-first change in a clean worktree.

Use automatically when a feature, refactor, or review involves domain language, bounded contexts, aggregates, entities, value objects, invariants, domain services, or business events; model only the domain complexity that is actually present.

Use automatically when behavior is failing, flaky, surprising, or environment-dependent; perform a bounded, evidence-led diagnosis before proposing or applying a fix.

Use automatically for document databases, key-value stores, wide-column data, search indexes, event records, schema evolution, partition keys, or non-relational persistence reviews.

Use automatically for frontend, UI, route, form, state, accessibility, responsive, or interaction work; shape a small vertical with explicit loading, empty, error, success, and real-browser evidence.

Use automatically when an accepted review must be summarized for a fresh agent, a task is being paused or resumed, or a vertical is ready for a human-owned merge, release, or deployment decision.

Use automatically when a change crosses an API, HTTP, web, RPC, message, webhook, or compatibility boundary; make contracts explicit and evolvable without privileging a framework.

Use automatically when changing a legacy boundary, schema, API, dependency, architecture, or data representation; create a staged, observable migration path with compatibility and rollback limits.

Use automatically when entering or resuming a Sillage worktree, when the project or task context is unclear, or when a fresh agent needs a concise status snapshot before acting.

Use automatically when a change depends on desktop, mobile, CLI, service, embedded, offline, process, filesystem, packaging, or operating-system behavior; keep platform policy at an explicit adapter boundary.

Use automatically when implementation needs tests, typechecks, builds, linters, screenshots, runtime checks, or domain validation before review; turn observable results into concise evidence.

Use automatically for SQL schema design, relational migrations, constraints, transactions, indexes, query performance, or persistence reviews; make invariants and rollback evidence explicit without over-modeling.

Use automatically when a task depends on unfamiliar, disputed, version-sensitive, or externally documented facts; read specifications, source code, papers, release notes, or tutorials and return a traceable evidence packet without polluting the repository.

Use automatically when a focused diff, pull request, change set, or implementation asks whether it is safe and complete; independently compare code and evidence with the approved Sillage slice.

Use automatically when a change handles identity, secrets, permissions, untrusted input, sensitive data, dependencies, or a trust boundary; produce a threat-informed security packet.

Use automatically when a request needs clarification, goals, context, alternatives, an architecture choice, an ADR, or an approved decision before implementation; ask one focused question at a time.

Use automatically as the single Sillage router for any material engineering task: orient a worktree, shape a decision, slice a feature, build, prove, review, hand off, or resume a blocked task without requiring a manual skill call.

Use automatically when an approved task must become one small vertical, worktree, branch, or independently reviewable implementation plan with explicit acceptance and non-goals.

Use automatically as a focused architecture or review lens when code changes raise responsibility boundaries, extension pressure, substitutability, interface size, or dependency direction; apply SOLID pragmatically without forcing object-oriented ceremony.

Use automatically when behavior depends on networks, concurrency, processes, queues, retries, time, resource limits, or partial failure; design for failure as a normal state.

Use automatically when tests are growing too quickly, duplicated, flaky, slow, unowned, or confusing; reduce the proof portfolio while preserving risk coverage and deterministic evidence.

Use automatically when designing a test strategy, choosing a seam, writing a regression, or deciding which test layer owns a risk; optimize for behavioral confidence, not test count.

Use when a developer says start Sillage, use Sillage, begin a task, continue in a fresh worktree, or asks how to work with the Sillage workflow; provide the simple entry ritual and hand off to the sillage router.