spec-driven-development

Specification-driven software development transforms ambiguous feature requests into testable specifications before implementation begins. You need it for new features, significant behavior changes, and multi-system work requiring acceptance criteria and shared terminology.

To turn vague ideas into clear implementation specs, define the project vocabulary, observable outcomes, constraints, non-goals, affected surfaces, gated approvals, and verification strategies to create a structured, testable development workflow.

Write acceptance criteria and non-goals by guiding the feature request through gated specification phases covering vocabulary, planning, task breakdown, implementation, and verification to define observable outcomes and explicit constraints.

The best way to plan complex multi-system software changes is to generate an approved specification with defined goals, constraints, and verification strategies before coding begins, ensuring shared terminology across teams.

You should not use a specification workflow for trivial changes that lack ambiguous requirements or complex multi-system interactions, as defining vocabulary, gated approvals, and observable outcomes adds unnecessary overhead.

Yes, the spec-driven-development skill works for new feature requests by converting broad requests into defined goals, constraints, acceptance criteria, and open questions to prevent costly rework before implementation.