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 plan, break into tasks, and implement.

Use it when starting a new project or feature, when requirements are ambiguous, when changes touch multiple modules, or when work exceeds roughly 30 minutes. Skip it for single-line fixes or typo corrections with unambiguous requirements.

Run the Phase 0 scope check: propose a capability map with stable kebab-case module ids, one-directional dependencies, and a build order. After human approval, write a separate spec per module in dependency order.

It adds upfront writing overhead, so it is not suited for trivial, self-contained changes. Its value depends on human review at each gate; skipping approvals turns the spec into documentation written after the fact.

Reframe each vague requirement as concrete success criteria with measurable targets, such as response time thresholds or coverage percentages, and confirm the targets with the human before proceeding to planning.