spec-driven-development

Start by listing your assumptions explicitly, then draft a spec covering six areas: objective, commands, project structure, code style, testing strategy, and boundaries. Have a human review and approve it before moving to planning and implementation.

Spec-driven development is a gated four-phase workflow: Specify, Plan, Tasks, Implement. Each phase requires human validation before advancing, and a Phase 0 scope check decomposes requests bundling multiple independently testable capabilities into a capability map.

Skip the full spec workflow 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 not the full gated process.

Run the Phase 0 scope check: if acceptance criteria cluster into independently testable groups, propose a capability map with stable kebab-case module ids, one-way dependencies, and a build order. Then run the full workflow per module in dependency order.

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

Code without a spec relies on implicit assumptions that surface as rework later. A short spec forces clarity on success criteria and boundaries before implementation, and serves as a living document referenced in PRs and updated when decisions change.