spec-driven-workflow

Topics in the source

• Spec-Driven Workflow — POWERFUL
• Overview
• Why Spec-First Matters
• The Iron Law
• The Spec Format
• Mandatory Sections
• RFC 2119 Keywords
• Bounded Autonomy Rules

Spec-driven workflow enforces a single, non-negotiable rule: write the specification BEFORE you write any code. Not alongside. Not after. Before. This is not documentation. This is a contract. A spec defines what the system MUST do, what it SHOULD do, and what it explicitly WILL NOT do. Every line of code you write traces back to a requirement in the spec. Every test traces back to an acceptance criterion. If it is not in the spec, it does not get built. 1. Eliminates rework. 60-80% of defects originate from requirements, not implementation. Catching ambiguity in a spec costs minutes; catching it in production costs days. 2. Forces clarity. If you cannot write what the system should do in plain language, you do not understand the problem well enough to write code. 3. Enables parallelism. Once a spec is approved, frontend, backend, QA, and documentation can all start simultaneously. 4. Creates accountability. The spec is the definition of done. No arguments about whether a feature is "complete" — either it satisfies the acceptance criteria or it does not. 5. Feeds TDD directly. Acceptance criteria in Given/When/Then format translate 1:1 into test cases. The spec IS the test plan. If

This is an excerpt. Refer to the complete source and its current requirements.