spec-driven-development

Follow the gated workflow: surface assumptions, write a spec covering objective, commands, project structure, code style, testing strategy, and boundaries, then get human approval. Reframe vague requirements into specific, testable success criteria before planning tasks.

Decompose when one requirement bundles several independently testable capabilities with distinct consumers or data, such as identity, billing, and notifications. Create a module table with stable kebab-case ids, one-way dependencies, and a build order before writing any module spec.

Skip the full spec process for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. Simple tasks still benefit from a two-line spec with acceptance criteria, but the gated workflow is unnecessary overhead.

Translate vague statements into concrete measurable conditions. For example, reframe "make the dashboard faster" as LCP under 2.5 seconds on 4G, initial data load under 500ms, and CLS under 0.1, then confirm these targets with the human.

The workflow adds upfront review time and is overkill for trivial changes. It also depends on human availability for phase gates, and specs must be actively maintained as living documents or they become stale and misleading.