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. Reframe vague requirements into specific, testable success criteria and get human approval before planning.

Use it for new projects or features, ambiguous requirements, changes touching multiple files, architectural decisions, or tasks taking more than 30 minutes. Skip it for single-line fixes, typos, or unambiguous self-contained changes.

Detect when one requirement bundles independently testable capabilities, then propose a capability map with 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.

Yes, the workflow is format-agnostic. If a project already uses OpenSpec or another specification system, keep that tool's artifact format and storage conventions while this workflow owns the clarification, content, and approval gates.

Specs require human review at each phase, which adds overhead for trivial changes. They also must be maintained as living documents when decisions or scope change, otherwise they drift out of sync with the implementation.