sdd-workflow

Run /spec with a task description to converse and produce spec.md and contract.md, approve the contract at Gate 1, then run /feature to implement one mini-feature at a time. Each mini-feature goes through implementation, judge review, and a micro-commit.

/spec converses and writes the contract then stops for approval, /feature implements one ready mini-feature at a time from an approved contract, and /fix is the escape hatch for small changes with an obvious cause that skips the spec and contract entirely.

Skip it for small scoped changes with an obvious cause and use /fix instead, which applies only the typed branch and the full Definition of Done. The full pipeline is designed for multi-step features where requirement ambiguity is costly.

TDD is opt-in per mini-feature. When enabled, the implementer writes failing tests first and stops at Gate 2 for human approval before any production code, logging a Red-Green-Refactor cycle with a scenario-to-test map.

Review is bounded to a maximum of 2 fix/re-review cycles. If a reviewer still requests changes after cycle 2, the mini-feature is marked blocked and a review-escalation file is written so the human decides, rather than the system choosing a side.

Yes. All state lives on disk under docs/specs/<slug>/ including spec.md, contract.md, features.json, and progress logs. Subagents write outputs to files and return only one-line references, so nothing depends on chat history.