spec-driven-development

Start by listing your assumptions explicitly, then write a spec covering six areas: objective, commands, project structure, code style, testing strategy, and boundaries. Have a human review and approve it before moving to planning and implementation.

It is a gated four-phase process: Specify, Plan, Tasks, then Implement. Each phase produces a reviewable artifact and requires human approval before advancing, ensuring the specification remains the shared source of truth.

Skip the full spec for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. Even simple tasks benefit from a two-line spec with acceptance criteria.

Create a capability map first: a table of modules with stable kebab-case ids, dependency direction, and build order. After human approval, run the full Specify-to-Implement cycle per module in dependency order.

Without a spec, implicit assumptions go unchecked and success is undefined, leading to rework. A short spec surfaces misunderstandings before code is written and converts vague requests into testable success criteria.