spec-driven-workflow

Run spec_generator.py with a feature name and description to produce a 9-section template covering context, functional requirements, acceptance criteria, edge cases, API contracts, data models, and out of scope. Fill every section using RFC 2119 keywords, then validate with spec_validator.py before implementation.

Run test_extractor.py against an approved spec file with a framework flag such as pytest. Each acceptance criterion and edge case becomes a failing test stub, which feeds directly into the red phase of test-driven development.

Spec-driven development defines what to build through requirements and acceptance criteria before coding starts. TDD defines how to implement via red-green-refactor cycles. The spec workflow produces test stubs in Phase 4, then TDD takes over for implementation.

Stop when requirement ambiguity exceeds 30 percent, when a change breaks an existing API contract or schema, when security areas like authentication or PII are touched, or when the work requires something not in the spec. Escalate with a specific question, options, and a recommendation.

Each criterion needs a concrete precondition (Given), a single trigger action (When), and observable outcomes like status codes or field values (Then). Avoid subjective words like fast or properly, and reference at least one requirement ID such as FR-3 in every criterion.