spec-driven-development

Spec-driven development requires a written specification before coding to eliminate guesswork. Use it when starting new projects, clarifying vague requirements, or implementing changes spanning multiple modules and architectural decisions.

Draft a complete specification by capturing six sections: Objective, Commands, Project Structure, Code Style, Testing Strategy, and Boundaries. Surface open questions, assumptions, and success criteria early to align stakeholders and reduce downstream rework.

A spec-guided workflow prevents drift using a phase-driven process: Specify, Plan, Tasks, and Implement. Human reviews at each stage ensure decisions and assumptions are validated as a living document before proceeding to code.

Yes, specification-driven planning is designed for complex changes spanning multiple modules. It captures architectural decisions and boundaries early, yielding a validated plan and actionable tasks to reduce ambiguity across interconnected components.

Manage assumptions and open questions by maintaining a living document specification. Capture decisions and success criteria early, then update the specification as the project evolves to ensure shared understanding and measurable success.

Coding without a specification leads to rework because requirements remain ambiguous and unstated. Defining specs first enforces shared understanding and measurable success criteria, preventing architectural drift and misaligned expectations.