spec-driven-development

Start with a requirements clarification stage to resolve ambiguities, then draft a spec covering objectives, scope, project structure, code style, testing strategy, and boundaries. Pause for explicit human approval before moving to planning or implementation.

A complete spec covers objectives, scope, project structure, code style, testing strategy, and boundaries including non-goals and constraints. Success criteria must be specific, measurable, and testable.

Trivial edits like typo fixes can skip the full pipeline with self-clarification only. However, even simple tasks benefit from a two-line spec with acceptance criteria, since the value lies in forcing clarity before code.

Under the make-feature pipeline, a subagent acting as an adversarial reviewer audits the spec for unstated assumptions, missing edge cases, security and architectural risks, and scope creep, iterating until it approves.

Under the make-feature pipeline, the spec is written to the feature worktree as spec.md inside the feature slug directory and committed to origin. Standalone specs outside git branches are stored as artifacts with feedback requested.