spec-driven-development

Write a spec covering six areas: objective, commands, project structure, code style, testing strategy, and boundaries. Surface your assumptions explicitly, reframe vague requirements into testable success criteria, and get human approval before writing any code.

Spec-driven development is a gated four-phase workflow: Specify, Plan, Tasks, Implement. Each phase requires human review before advancing, and a Phase 0 scope check decomposes multi-capability requests into a capability map first.

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

Create a capability map listing module ids, responsibilities, and dependencies with a build order. Use stable kebab-case module ids, ensure one-way dependency direction, and get the map approved before writing per-module specs.

Yes, the workflow is format-agnostic. If your 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.