gate-sdd

Sweep shipped specs out of .specs/ into .specs/_archive/ and set Status archived, so a session globbing .specs/ sees only live work. Use on request, when .specs/ has accumulated enough finished work to be noise — not after every merge.

Order the whole of the known work into a product backlog, with an explicit critical path and reasons for the order. Use after epics, and to re-groom when reality diverges. Creates no issues — sprint does that.

Interrogate a draft spec's Requirements for ambiguity before any Design or Tasks exist — at most 5 targeted questions, answers recorded in the spec. Use between drafting Requirements and writing the rest.

Write the development contract — the language, style, testing, and review rules this project holds itself to — and compile the enforceable ones into the reviewer's rulebook. Use at project inception, or when recurring review findings reveal an unwritten rule.

Write the technical design — the architecture, the seams between components, and the decisions worth recording as ADRs. Use after the PRD and before the backlog, or when a capability needs a design bigger than one spec.

Decompose capabilities into epics — chunks of work with a demonstrable outcome — each grouping the issues that specs will be written from. Use between the PRD and the backlog.

Execute an approved .specs/<slug>/spec.md through the TDD Red-Green-Refactor loop, then pass the mandatory reviewer gate before any PR. Use after a spec has been reviewed and approved.

Set up this SDD harness in a project — detect the toolchain, interview for what cannot be inferred, and write .steering, .specs, .work_logs, a project-specific reviewer, and the hooks. Use once per project, or to migrate a project that already has parts of the harness.

Name the one metric this product moves, the levers that move it, and the quality property a defect would most damage. Use at project inception, before the PRD. Produces the anchor that every reviewer severity is judged against.

Write the product requirements — who it is for, what capabilities it must have, what it deliberately is not — with stable capability ids that specs cite. Use at project inception, after northstar and before any technical design.

Turn a feature idea or tracker issue into ONE reviewable spec — Requirements, Design, TDD-ordered Tasks — under .specs/. Use at the start of any new feature, before writing code.

Decompose the top of the product backlog into typed tracker issues for this iteration — each sized as one issue, one branch, one spec, one PR. Use at the start of an iteration. This is where a plan becomes committed work.

Append a dated entry to .work_logs/ summarizing what changed this session — activities, decisions, next steps. Use at the end of a working session or right after implement.