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. Only after approval do you generate a plan, break it into tasks, and implement.

Use it when starting a new project or feature, when requirements are ambiguous, when changes touch multiple files, or when work exceeds 30 minutes. Skip it for single-line fixes, typos, or unambiguous self-contained changes.

Run the Phase 0 scope check: propose a capability map with stable kebab-case module ids, one-way dependencies, and a build order. After human approval, run the full Specify-Plan-Tasks-Implement cycle per module in dependency order.

It adds upfront review overhead, so it is overkill for trivial fixes. Its value depends on human review at each gate; skipping approvals turns the spec into documentation written after the fact rather than a source of truth.

Reframe each vague requirement as concrete success criteria with measurable targets, such as response time thresholds or coverage percentages, then confirm the targets with the human before writing the spec.