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.

Spec-driven development is a workflow where a written specification serves as the source of truth before any code is written. It follows four gated phases: Specify, Plan, Tasks, and Implement, each validated by human review.

Skip the full spec process 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.

Reframe vague requests into specific, testable conditions. For example, "make the dashboard faster" becomes measurable targets like LCP under 2.5 seconds on 4G and CLS under 0.1, then confirm those targets with the requester.

The spec is a living document that must be updated when decisions or scope change, or it becomes stale. It also adds upfront time, though roughly 15 minutes of specification typically prevents hours of rework.