spec-driven-development

Gather requirements into functional, non-functional, and boundary categories, then document user stories, API surface, data model, acceptance criteria, and testing strategy in a single spec file. This Skill generates that document at a numbered path like specs/S-NNN-feature-name.md.

A good acceptance criterion is specific, testable, independent, and covers both success and failure paths. Vague statements like "handles errors gracefully" are rejected in favor of concrete conditions specifying the error, user-visible result, and system state.

Ask up to two clarifying questions rather than filling gaps with assumptions. Any unresolved assumption is flagged explicitly as "ASSUMED: [assumption]" for review, and blocking unknowns are listed in the Open Questions section.

Yes. The workflow includes a codebase analysis step that examines architecture patterns, style conventions, adjacent features, and shared types, then documents these findings as Existing Patterns so implementors have the necessary context.

Update the spec whenever requirements change during implementation, since it remains the single source of truth. Implementation should never start from a spec with open questions in critical areas.