[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KBFC5C0GFPJFSVDH3PA7T0":3,"skill-same:01M6KBFC5C0GFPJFSVDH3PA7T0":104},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6KBFC5C0GFPJFSVDH3PA7T0","spec-driven-workflow",null,"Use when the user asks to write specs before code, define acceptance criteria, plan features before implementation, generate tests from specifications, or follow spec-first development practices.","afaizalam2003\u002FMaster-claude-skill","afaizalam2003","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F222019359?v=4","01M6K8F2XNT0HKBPF00JQ78SV3","Faiz Alam","01M6K8F31EBXAPER0EG8R9HTR5",3,"MIT","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fspec-driven-workflow\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"workflow","driven","spec driven workflow","spec driven","spec","code","generate","acceptance","first","plan","write","development","use","generate tests","implementation","acceptance criteria","define","tests","specifications","features","2026-11-10 10:12:30",false,"---\nname: \"spec-driven-workflow\"\ndescription: \"Use when the user asks to write specs before code, define acceptance criteria, plan features before implementation, generate tests from specifications, or follow spec-first development practices.\"\n---\n\n# Spec-Driven Workflow — POWERFUL\n\n## Overview\n\nSpec-driven workflow enforces a single, non-negotiable rule: **write the specification BEFORE you write any code.** Not alongside. Not after. Before.\n\nThis 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.\n\n### Why Spec-First Matters\n\n1. **Eliminates rework.** 60-80% of defects originate from requirements, not implementation. Catching ambiguity in a spec costs minutes; catching it in production costs days.\n2. **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.\n3. **Enables parallelism.** Once a spec is approved, frontend, backend, QA, and documentation can all start simultaneously.\n4. **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.\n5. **Feeds TDD directly.** Acceptance criteria in Given\u002FWhen\u002FThen format translate 1:1 into test cases. The spec IS the test plan.\n\n### The Iron Law\n\n```\nNO CODE WITHOUT AN APPROVED SPEC.\nNO EXCEPTIONS. NO \"QUICK PROTOTYPES.\" NO \"I'LL DOCUMENT IT LATER.\"\n```\n\nIf the spec is not written, reviewed, and approved, implementation does not begin. Period.\n\n---\n\n## The Spec Format\n\nEvery spec follows this structure. No sections are optional — if a section does not apply, write \"N\u002FA — [reason]\" so reviewers know it was considered, not forgotten.\n\n### Mandatory Sections\n\n| # | Section | Key Rules |\n|---|---------|-----------|\n| 1 | **Title and Metadata** | Author, date, status (Draft\u002FIn Review\u002FApproved\u002FSuperseded), reviewers |\n| 2 | **Context** | Why this feature exists. 2-4 paragraphs with evidence (metrics, tickets). |\n| 3 | **Functional Requirements** | RFC 2119 keywords (MUST\u002FSHOULD\u002FMAY). Numbered FR-N. Each is atomic and testable. |\n| 4 | **Non-Functional Requirements** | Performance, security, accessibility, scalability, reliability — all with measurable thresholds. |\n| 5 | **Acceptance Criteria** | Given\u002FWhen\u002FThen format. Every AC references at least one FR-* or NFR-*. |\n| 6 | **Edge Cases** | Numbered EC-N. Cover failure modes for every external dependency. |\n| 7 | **API Contracts** | TypeScript-style interfaces. Cover success and error responses. |\n| 8 | **Data Models** | Table format with field, type, constraints. Every entity from requirements must have a model. |\n| 9 | **Out of Scope** | Explicit exclusions with reasons. Prevents scope creep during implementation. |\n\n### RFC 2119 Keywords\n\n| Keyword | Meaning |\n|---------|---------|\n| **MUST** | Absolute requirement. Non-conformant without it. |\n| **MUST NOT** | Absolute prohibition. |\n| **SHOULD** | Recommended. Omit only with documented justification. |\n| **MAY** | Optional. Implementer's discretion. |\n\nSee [spec_format_guide.md](references\u002Fspec_format_guide.md) for the complete template with section-by-section examples, good\u002Fbad requirement patterns, and feature-type templates (CRUD, Integration, Migration).\n\nSee [acceptance_criteria_patterns.md](references\u002Facceptance_criteria_patterns.md) for a full pattern library of Given\u002FWhen\u002FThen criteria across authentication, CRUD, search, file upload, payment, notification, and accessibility scenarios.\n\n---\n\n## Bounded Autonomy Rules\n\nThese rules define when an agent (human or AI) MUST stop and ask for guidance vs. when they can proceed independently.\n\n### STOP and Ask When:\n\n1. **Scope creep detected.** The implementation requires something not in the spec. Even if it seems obviously needed, STOP. The spec might have excluded it deliberately.\n\n2. **Ambiguity exceeds 30%.** If you cannot determine the correct behavior from the spec for more than 30% of a given requirement, the spec is incomplete. Do not guess.\n\n3. **Breaking changes required.** The implementation would change an existing API contract, database schema, or public interface. Always escalate.\n\n4. **Security implications.** Any change that touches authentication, authorization, encryption, or PII handling requires explicit approval.\n\n5. **Performance characteristics unknown.** If a requirement says \"MUST complete in \u003C 500ms\" but you have no way to measure or guarantee that, escalate before implementing a guess.\n\n6. **Cross-team dependencies.** If the spec requires coordination with another team or service, confirm the dependency before building against it.\n\n### Continue Autonomously When:\n\n1. **Spec is clear and unambiguous** for the current task.\n2. **All acceptance criteria have passing tests** and you are refactoring internals.\n3. **Changes are non-breaking** — no public API, schema, or behavior changes.\n4. **Implementation is a direct translation** of a well-defined acceptance criterion.\n5. **Error handling follows established patterns** already documented in the codebase.\n\n### Escalation Protocol\n\nWhen you must stop, provide:\n\n```markdown\n## Escalation: [Brief Title]\n\n**Blocked on:** [requirement ID, e.g., FR-3]\n**Question:** [Specific, answerable question — not \"what should I do?\"]\n**Options considered:**\n  A. [Option] — Pros: [...] Cons: [...]\n  B. [Option] — Pros: [...] Cons: [...]\n**My recommendation:** [A or B, with reasoning]\n**Impact of waiting:** [What is blocked until this is resolved?]\n```\n\nNever escalate without a recommendation. Never present an open-ended question. Always give options.\n\nSee `references\u002Fbounded_autonomy_rules.md` for the complete decision matrix.\n\n---\n\n## Workflow — 6 Phases\n\n### Phase 1: Gather Requirements\n\n**Goal:** Understand what needs to be built and why.\n\n1. **Interview the user.** Ask:\n   - What problem does this solve?\n   - Who are the users?\n   - What does success look like?\n   - What explicitly should NOT be built?\n2. **Read existing code.** Understand the current system before proposing changes.\n3. **Identify constraints.** Performance budgets, security requirements, backward compatibility.\n4. **List unknowns.** Every unknown is a risk. Surface them now, not during implementation.\n\n**Exit criteria:** You can explain the feature to someone unfamiliar with the project in 2 minutes.\n\n### Phase 2: Write Spec\n\n**Goal:** Produce a complete spec document following The Spec Format above.\n\n1. Fill every section of the template. No section left blank.\n2. Number all requirements (FR-*, NFR-*, AC-*, EC-*, OS-*).\n3. Use RFC 2119 keywords precisely.\n4. Write acceptance criteria in Given\u002FWhen\u002FThen format.\n5. Define API contracts with TypeScript-style types.\n6. List explicit exclusions in Out of Scope.\n\n**Exit criteria:** The spec can be handed to a developer who was not in the requirements meeting, and they can implement the feature without asking clarifying questions.\n\n### Phase 3: Validate Spec\n\n**Goal:** Verify the spec is complete, consistent, and implementable.\n\nRun `spec_validator.py` against the spec file:\n\n```bash\npython spec_validator.py --file spec.md --strict\n```\n\nManual validation checklist:\n- [ ] Every functional requirement has at least one acceptance criterion\n- [ ] Every acceptance criterion is testable (no subjective language)\n- [ ] API contracts cover all endpoints mentioned in requirements\n- [ ] Data models cover all entities mentioned in requirements\n- [ ] Edge cases cover failure modes for every external dependency\n- [ ] Out of scope is explicit about what was considered and rejected\n- [ ] Non-functional requirements have measurable thresholds\n\n**Exit criteria:** Spec scores 80+ on validator, and all manual checklist items pass.\n\n### Phase 4: Generate Tests\n\n**Goal:** Extract test cases from acceptance criteria before writing implementation code.\n\nRun `test_extractor.py` against the approved spec:\n\n```bash\npython test_extractor.py --file spec.md --framework pytest --output tests\u002F\n```\n\n1. Each acceptance criterion becomes one or more test cases.\n2. Each edge case becomes a test case.\n3. Tests are stubs — they define the assertion but not the implementation.\n4. All tests MUST fail initially (red phase of TDD).\n\n**Exit criteria:** You have a test file where every test fails with \"not implemented\" or equivalent.\n\n### Phase 5: Implement\n\n**Goal:** Write code that makes failing tests pass, one acceptance criterion at a time.\n\n1. Pick one acceptance criterion (start with the simplest).\n2. Make its test(s) pass with minimal code.\n3. Run the full test suite — no regressions.\n4. Commit.\n5. Pick the next acceptance criterion. Repeat.\n\n**Rules:**\n- Do NOT implement anything not in the spec.\n- Do NOT optimize before all acceptance criteria pass.\n- Do NOT refactor before all acceptance criteria pass.\n- If you discover a missing requirement, STOP and update the spec first.\n\n**Exit criteria:** All tests pass. All acceptance criteria satisfied.\n\n### Phase 6: Self-Review\n\n**Goal:** Verify implementation matches spec before marking done.\n\nRun through the Self-Review Checklist below. If any item fails, fix it before declaring the task complete.\n\n---\n\n## Self-Review Checklist\n\nBefore marking any implementation as done, verify ALL of the following:\n\n- [ ] **Every acceptance criterion has a passing test.** No exceptions. If AC-3 exists, a test for AC-3 exists and passes.\n- [ ] **Every edge case has a test.** EC-1 through EC-N all have corresponding test cases.\n- [ ] **No scope creep.** The implementation does not include features not in the spec. If you added something, either update the spec or remove it.\n- [ ] **API contracts match implementation.** Request\u002Fresponse shapes in code match the spec exactly. Field names, types, status codes — all of it.\n- [ ] **Error scenarios tested.** Every error response defined in the spec has a test that triggers it.\n- [ ] **Non-functional requirements verified.** If the spec says \u003C 500ms, you have evidence (benchmark, load test, profiling) that it meets the threshold.\n- [ ] **Data model matches.** Database schema matches the spec. No extra columns, no missing constraints.\n- [ ] **Out-of-scope items not built.** Double-check that nothing from the Out of Scope section leaked into the implementation.\n\n---\n\n## Integration with TDD Guide\n\nSpec-driven workflow and TDD are complementary, not competing:\n\n```\nSpec-Driven Workflow          TDD (Red-Green-Refactor)\n─────────────────────         ──────────────────────────\nPhase 1: Gather Requirements\nPhase 2: Write Spec\nPhase 3: Validate Spec\nPhase 4: Generate Tests  ──→  RED: Tests exist and fail\nPhase 5: Implement       ──→  GREEN: Minimal code to pass\nPhase 6: Self-Review     ──→  REFACTOR: Clean up internals\n```\n\n**The handoff:** Spec-driven workflow produces the test stubs (Phase 4). TDD takes over from there. The spec tells you WHAT to test. TDD tells you HOW to implement.\n\nUse `engineering-team\u002Ftdd-guide` for:\n- Red-green-refactor cycle discipline\n- Coverage analysis and gap detection\n- Framework-specific test patterns (Jest, Pytest, JUnit)\n\nUse `engineering\u002Fspec-driven-workflow` for:\n- Defining what to build before building it\n- Acceptance criteria authoring\n- Completeness validation\n- Scope control\n\n---\n\n## Examples\n\nA complete worked example (Password Reset spec with extracted test cases) is available in [spec_format_guide.md](references\u002Fspec_format_guide.md#full-example-password-reset). It demonstrates all 9 sections, requirement numbering, acceptance criteria, edge cases, and the corresponding pytest stubs generated by `test_extractor.py`.\n\n---\n\n## Anti-Patterns\n\n### 1. Coding Before Spec Approval\n\n**Symptom:** \"I'll start coding while the spec is being reviewed.\"\n**Problem:** The review will surface changes. Now you have code that implements a rejected design.\n**Rule:** Implementation does not begin until spec status is \"Approved.\"\n\n### 2. Vague Acceptance Criteria\n\n**Symptom:** \"The system should work well\" or \"The UI should be responsive.\"\n**Problem:** Untestable. What does \"well\" mean? What does \"responsive\" mean?\n**Rule:** Every acceptance criterion must be verifiable by a machine. If you cannot write a test for it, rewrite the criterion.\n\n### 3. Missing Edge Cases\n\n**Symptom:** Happy path is specified, error paths are not.\n**Problem:** Developers invent error handling on the fly, leading to inconsistent behavior.\n**Rule:** For every external dependency (API, database, file system, user input), specify at least one failure scenario.\n\n### 4. Spec as Post-Hoc Documentation\n\n**Symptom:** \"Let me write the spec now that the feature is done.\"\n**Problem:** This is documentation, not specification. It describes what was built, not what should have been built. It cannot catch design errors because the design is already frozen.\n**Rule:** If the spec was written after the code, it is not a spec. Relabel it as documentation.\n\n### 5. Gold-Plating Beyond Spec\n\n**Symptom:** \"While I was in there, I also added...\"\n**Problem:** Untested code. Unreviewed design. Potential for subtle bugs in the \"bonus\" feature.\n**Rule:** If it is not in the spec, it does not get built. File a new spec for additional features.\n\n### 6. Acceptance Criteria Without Requirement Traceability\n\n**Symptom:** AC-7 exists but does not reference any FR-* or NFR-*.\n**Problem:** Orphaned criteria mean either a requirement is missing or the criterion is unnecessary.\n**Rule:** Every AC-* MUST reference at least one FR-* or NFR-*.\n\n### 7. Skipping Validation\n\n**Symptom:** \"The spec looks fine, let's just start.\"\n**Problem:** Missing sections discovered during implementation cause blocking delays.\n**Rule:** Always run `spec_validator.py --strict` before starting implementation. Fix all warnings.\n\n---\n\n## Cross-References\n\n- **`engineering-team\u002Ftdd-guide`** — Red-green-refactor cycle, test generation, coverage analysis. Use after Phase 4 of this workflow.\n- **`engineering\u002Ffocused-fix`** — Deep-dive feature repair. When a spec-driven implementation has systemic issues, use focused-fix for diagnosis.\n- **`engineering\u002Frag-architect`** — If the feature involves retrieval or knowledge systems, use rag-architect for the technical design within the spec.\n- **`references\u002Fspec_format_guide.md`** — Complete template with section-by-section explanations.\n- **`references\u002Fbounded_autonomy_rules.md`** — Full decision matrix for when to stop vs. continue.\n- **`references\u002Facceptance_criteria_patterns.md`** — Pattern library for writing Given\u002FWhen\u002FThen criteria.\n\n---\n\n## Tools\n\n| Script | Purpose | Key Flags |\n|--------|---------|-----------|\n| `spec_generator.py` | Generate spec template from feature name\u002Fdescription | `--name`, `--description`, `--format`, `--json` |\n| `spec_validator.py` | Validate spec completeness (0-100 score) | `--file`, `--strict`, `--json` |\n| `test_extractor.py` | Extract test stubs from acceptance criteria | `--file`, `--framework`, `--output`, `--json` |\n\n```bash\n# Generate a spec template\npython spec_generator.py --name \"User Authentication\" --description \"OAuth 2.0 login flow\"\n\n# Validate a spec\npython spec_validator.py --file specs\u002Fauth.md --strict\n\n# Extract test cases\npython test_extractor.py --file specs\u002Fauth.md --framework pytest --output tests\u002Ftest_auth.py\n```\n","# Spec-Driven Workflow — POWERFUL\n\n## Overview\n\nSpec-driven workflow enforces a single, non-negotiable rule: **write the specification BEFORE you write any code.** Not alongside. Not after. Before.\n\nThis 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.\n\n### Why Spec-First Matters\n\n1. **Eliminates rework.** 60-80% of defects originate from requirements, not implementation. Catching ambiguity in a spec costs minutes; catching it in production costs days.\n2. **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.\n3. **Enables parallelism.** Once a spec is approved, frontend, backend, QA, and documentation can all start simultaneously.\n4. **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.\n5. **Feeds TDD directly.** Acceptance criteria in Given\u002FWhen\u002FThen format translate 1:1 into test cases. The spec IS the test plan.\n\n### The Iron Law\n\n```\nNO CODE WITHOUT AN APPROVED SPEC.\nNO EXCEPTIONS. NO \"QUICK PROTOTYPES.\" NO \"I'LL DOCUMENT IT LATER.\"\n```\n\nIf the spec is not written, reviewed, and approved, implementation does not begin. Period.\n\n---\n\n## The Spec Format\n\nEvery spec follows this structure. No sections are optional — if a section does not apply, write \"N\u002FA — [reason]\" so reviewers know it was considered, not forgotten.\n\n### Mandatory Sections\n\n| # | Section | Key Rules |\n|---|---------|-----------|\n| 1 | **Title and Metadata** | Author, date, status (Draft\u002FIn Review\u002FApproved\u002FSuperseded), reviewers |\n| 2 | **Context** | Why this feature exists. 2-4 paragraphs with evidence (metrics, tickets). |\n| 3 | **Functional Requirements** | RFC 2119 keywords (MUST\u002FSHOULD\u002FMAY). Numbered FR-N. Each is atomic and testable. |\n| 4 | **Non-Functional Requirements** | Performance, security, accessibility, scalability, reliability — all with measurable thresholds. |\n| 5 | **Acceptance Criteria** | Given\u002FWhen\u002FThen format. Every AC references at least one FR-* or NFR-*. |\n| 6 | **Edge Cases** | Numbered EC-N. Cover failure modes for every external dependency. |\n| 7 | **API Contracts** | TypeScript-style interfaces. Cover success and error responses. |\n| 8 | **Data Models** | Table format with field, type, constraints. Every entity from requirements must have a model. |\n| 9 | **Out of Scope** | Explicit exclusions with reasons. Prevents scope creep during implementation. |\n\n### RFC 2119 Keywords\n\n| Keyword | Meaning |\n|---------|---------|\n| **MUST** | Absolute requirement. Non-conformant without it. |\n| **MUST NOT** | Absolute prohibition. |\n| **SHOULD** | Recommended. Omit only with documented justification. |\n| **MAY** | Optional. Implementer's discretion. |\n\nSee [spec_format_guide.md](references\u002Fspec_format_guide.md) for the complete template with section-by-section examples, good\u002Fbad requirement patterns, and feature-type templates (CRUD, Integration, Migration).\n\nSee [acceptance_criteria_patterns.md](references\u002Facceptance_criteria_patterns.md) for a full pattern library of Given\u002FWhen\u002FThen criteria across authentication, CRUD, search, file upload, payment, notification, and accessibility scenarios.\n\n---\n\n## Bounded Autonomy Rules\n\nThese rules define when an agent (human or AI) MUST stop and ask for guidance vs. when they can proceed independently.\n\n### STOP and Ask When:\n\n1. **Scope creep detected.** The implementation requires something not in the spec. Even if it seems obviously needed, STOP. The spec might have excluded it deliberately.\n\n2. **Ambiguity exceeds 30%.** If you cannot determine the correct behavior from the spec for more than 30% of a given requirement, the spec is incomplete. Do not guess.\n\n3. **Breaking changes required.** The implementation would change an existing API contract, database schema, or public interface. Always escalate.\n\n4. **Security implications.** Any change that touches authentication, authorization, encryption, or PII handling requires explicit approval.\n\n5. **Performance characteristics unknown.** If a requirement says \"MUST complete in \u003C 500ms\" but you have no way to measure or guarantee that, escalate before implementing a guess.\n\n6. **Cross-team dependencies.** If the spec requires coordination with another team or service, confirm the dependency before building against it.\n\n### Continue Autonomously When:\n\n1. **Spec is clear and unambiguous** for the current task.\n2. **All acceptance criteria have passing tests** and you are refactoring internals.\n3. **Changes are non-breaking** — no public API, schema, or behavior changes.\n4. **Implementation is a direct translation** of a well-defined acceptance criterion.\n5. **Error handling follows established patterns** already documented in the codebase.\n\n### Escalation Protocol\n\nWhen you must stop, provide:\n\n```markdown\n## Escalation: [Brief Title]\n\n**Blocked on:** [requirement ID, e.g., FR-3]\n**Question:** [Specific, answerable question — not \"what should I do?\"]\n**Options considered:**\n  A. [Option] — Pros: [...] Cons: [...]\n  B. [Option] — Pros: [...] Cons: [...]\n**My recommendation:** [A or B, with reasoning]\n**Impact of waiting:** [What is blocked until this is resolved?]\n```\n\nNever escalate without a recommendation. Never present an open-ended question. Always give options.\n\nSee `references\u002Fbounded_autonomy_rules.md` for the complete decision matrix.\n\n---\n\n## Workflow — 6 Phases\n\n### Phase 1: Gather Requirements\n\n**Goal:** Understand what needs to be built and why.\n\n1. **Interview the user.** Ask:\n   - What problem does this solve?\n   - Who are the users?\n   - What does success look like?\n   - What explicitly should NOT be built?\n2. **Read existing code.** Understand the current system before proposing changes.\n3. **Identify constraints.** Performance budgets, security requirements, backward compatibility.\n4. **List unknowns.** Every unknown is a risk. Surface them now, not during implementation.\n\n**Exit criteria:** You can explain the feature to someone unfamiliar with the project in 2 minutes.\n\n### Phase 2: Write Spec\n\n**Goal:** Produce a complete spec document following The Spec Format above.\n\n1. Fill every section of the template. No section left blank.\n2. Number all requirements (FR-*, NFR-*, AC-*, EC-*, OS-*).\n3. Use RFC 2119 keywords precisely.\n4. Write acceptance criteria in Given\u002FWhen\u002FThen format.\n5. Define API contracts with TypeScript-style types.\n6. List explicit exclusions in Out of Scope.\n\n**Exit criteria:** The spec can be handed to a developer who was not in the requirements meeting, and they can implement the feature without asking clarifying questions.\n\n### Phase 3: Validate Spec\n\n**Goal:** Verify the spec is complete, consistent, and implementable.\n\nRun `spec_validator.py` against the spec file:\n\n```bash\npython spec_validator.py --file spec.md --strict\n```\n\nManual validation checklist:\n- [ ] Every functional requirement has at least one acceptance criterion\n- [ ] Every acceptance criterion is testable (no subjective language)\n- [ ] API contracts cover all endpoints mentioned in requirements\n- [ ] Data models cover all entities mentioned in requirements\n- [ ] Edge cases cover failure modes for every external dependency\n- [ ] Out of scope is explicit about what was considered and rejected\n- [ ] Non-functional requirements have measurable thresholds\n\n**Exit criteria:** Spec scores 80+ on validator, and all manual checklist items pass.\n\n### Phase 4: Generate Tests\n\n**Goal:** Extract test cases from acceptance criteria before writing implementation code.\n\nRun `test_extractor.py` against the approved spec:\n\n```bash\npython test_extractor.py --file spec.md --framework pytest --output tests\u002F\n```\n\n1. Each acceptance criterion becomes one or more test cases.\n2. Each edge case becomes a test case.\n3. Tests are stubs — they define the assertion but not the implementation.\n4. All tests MUST fail initially (red phase of TDD).\n\n**Exit criteria:** You have a test file where every test fails with \"not implemented\" or equivalent.\n\n### Phase 5: Implement\n\n**Goal:** Write code that makes failing tests pass, one acceptance criterion at a time.\n\n1. Pick one acceptance criterion (start with the simplest).\n2. Make its test(s) pass with minimal code.\n3. Run the full test suite — no regressions.\n4. Commit.\n5. Pick the next acceptance criterion. Repeat.\n\n**Rules:**\n- Do NOT implement anything not in the spec.\n- Do NOT optimize before all acceptance criteria pass.\n- Do NOT refactor before all acceptance criteria pass.\n- If you discover a missing requirement, STOP and update the spec first.\n\n**Exit criteria:** All tests pass. All acceptance criteria satisfied.\n\n### Phase 6: Self-Review\n\n**Goal:** Verify implementation matches spec before marking done.\n\nRun through the Self-Review Checklist below. If any item fails, fix it before declaring the task complete.\n\n---\n\n## Self-Review Checklist\n\nBefore marking any implementation as done, verify ALL of the following:\n\n- [ ] **Every acceptance criterion has a passing test.** No exceptions. If AC-3 exists, a test for AC-3 exists and passes.\n- [ ] **Every edge case has a test.** EC-1 through EC-N all have corresponding test cases.\n- [ ] **No scope creep.** The implementation does not include features not in the spec. If you added something, either update the spec or remove it.\n- [ ] **API contracts match implementation.** Request\u002Fresponse shapes in code match the spec exactly. Field names, types, status codes — all of it.\n- [ ] **Error scenarios tested.** Every error response defined in the spec has a test that triggers it.\n- [ ] **Non-functional requirements verified.** If the spec says \u003C 500ms, you have evidence (benchmark, load test, profiling) that it meets the threshold.\n- [ ] **Data model matches.** Database schema matches the spec. No extra columns, no missing constraints.\n- [ ] **Out-of-scope items not built.** Double-check that nothing from the Out of Scope section leaked into the implementation.\n\n---\n\n## Integration with TDD Guide\n\nSpec-driven workflow and TDD are complementary, not competing:\n\n```\nSpec-Driven Workflow          TDD (Red-Green-Refactor)\n─────────────────────         ──────────────────────────\nPhase 1: Gather Requirements\nPhase 2: Write Spec\nPhase 3: Validate Spec\nPhase 4: Generate Tests  ──→  RED: Tests exist and fail\nPhase 5: Implement       ──→  GREEN: Minimal code to pass\nPhase 6: Self-Review     ──→  REFACTOR: Clean up internals\n```\n\n**The handoff:** Spec-driven workflow produces the test stubs (Phase 4). TDD takes over from there. The spec tells you WHAT to test. TDD tells you HOW to implement.\n\nUse `engineering-team\u002Ftdd-guide` for:\n- Red-green-refactor cycle discipline\n- Coverage analysis and gap detection\n- Framework-specific test patterns (Jest, Pytest, JUnit)\n\nUse `engineering\u002Fspec-driven-workflow` for:\n- Defining what to build before building it\n- Acceptance criteria authoring\n- Completeness validation\n- Scope control\n\n---\n\n## Examples\n\nA complete worked example (Password Reset spec with extracted test cases) is available in [spec_format_guide.md](references\u002Fspec_format_guide.md#full-example-password-reset). It demonstrates all 9 sections, requirement numbering, acceptance criteria, edge cases, and the corresponding pytest stubs generated by `test_extractor.py`.\n\n---\n\n## Anti-Patterns\n\n### 1. Coding Before Spec Approval\n\n**Symptom:** \"I'll start coding while the spec is being reviewed.\"\n**Problem:** The review will surface changes. Now you have code that implements a rejected design.\n**Rule:** Implementation does not begin until spec status is \"Approved.\"\n\n### 2. Vague Acceptance Criteria\n\n**Symptom:** \"The system should work well\" or \"The UI should be responsive.\"\n**Problem:** Untestable. What does \"well\" mean? What does \"responsive\" mean?\n**Rule:** Every acceptance criterion must be verifiable by a machine. If you cannot write a test for it, rewrite the criterion.\n\n### 3. Missing Edge Cases\n\n**Symptom:** Happy path is specified, error paths are not.\n**Problem:** Developers invent error handling on the fly, leading to inconsistent behavior.\n**Rule:** For every external dependency (API, database, file system, user input), specify at least one failure scenario.\n\n### 4. Spec as Post-Hoc Documentation\n\n**Symptom:** \"Let me write the spec now that the feature is done.\"\n**Problem:** This is documentation, not specification. It describes what was built, not what should have been built. It cannot catch design errors because the design is already frozen.\n**Rule:** If the spec was written after the code, it is not a spec. Relabel it as documentation.\n\n### 5. Gold-Plating Beyond Spec\n\n**Symptom:** \"While I was in there, I also added...\"\n**Problem:** Untested code. Unreviewed design. Potential for subtle bugs in the \"bonus\" feature.\n**Rule:** If it is not in the spec, it does not get built. File a new spec for additional features.\n\n### 6. Acceptance Criteria Without Requirement Traceability\n\n**Symptom:** AC-7 exists but does not reference any FR-* or NFR-*.\n**Problem:** Orphaned criteria mean either a requirement is missing or the criterion is unnecessary.\n**Rule:** Every AC-* MUST reference at least one FR-* or NFR-*.\n\n### 7. Skipping Validation\n\n**Symptom:** \"The spec looks fine, let's just start.\"\n**Problem:** Missing sections discovered during implementation cause blocking delays.\n**Rule:** Always run `spec_validator.py --strict` before starting implementation. Fix all warnings.\n\n---\n\n## Cross-References\n\n- **`engineering-team\u002Ftdd-guide`** — Red-green-refactor cycle, test generation, coverage analysis. Use after Phase 4 of this workflow.\n- **`engineering\u002Ffocused-fix`** — Deep-dive feature repair. When a spec-driven implementation has systemic issues, use focused-fix for diagnosis.\n- **`engineering\u002Frag-architect`** — If the feature involves retrieval or knowledge systems, use rag-architect for the technical design within the spec.\n- **`references\u002Fspec_format_guide.md`** — Complete template with section-by-section explanations.\n- **`references\u002Fbounded_autonomy_rules.md`** — Full decision matrix for when to stop vs. continue.\n- **`references\u002Facceptance_criteria_patterns.md`** — Pattern library for writing Given\u002FWhen\u002FThen criteria.\n\n---\n\n## Tools\n\n| Script | Purpose | Key Flags |\n|--------|---------|-----------|\n| `spec_generator.py` | Generate spec template from feature name\u002Fdescription | `--name`, `--description`, `--format`, `--json` |\n| `spec_validator.py` | Validate spec completeness (0-100 score) | `--file`, `--strict`, `--json` |\n| `test_extractor.py` | Extract test stubs from acceptance criteria | `--file`, `--framework`, `--output`, `--json` |\n\n```bash\n# Generate a spec template\npython spec_generator.py --name \"User Authentication\" --description \"OAuth 2.0 login flow\"\n\n# Validate a spec\npython spec_validator.py --file specs\u002Fauth.md --strict\n\n# Extract test cases\npython test_extractor.py --file specs\u002Fauth.md --framework pytest --output tests\u002Ftest_auth.py\n```\n",{"name":5,"description":7},"main","0b48cbb0e6d5be6ff68c0f6b28bc0c65ee21c4a1","engineering\u002Fspec-driven-workflow",2,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill","https:\u002F\u002Fgithub.com\u002Fafaizalam2003","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fmdfaizalam2003\u002F","2026-04-01 04:35:43",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add afaizalam2003\u002FMaster-claude-skill --skill spec-driven-workflow",{"tool":68,"command":69},"bunx","bunx skills add afaizalam2003\u002FMaster-claude-skill --skill spec-driven-workflow",{"tool":71,"command":72},"pnpm","pnpm dlx skills add afaizalam2003\u002FMaster-claude-skill --skill spec-driven-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fspec-driven-workflow\u002FSKILL.md",true,[76,82,86,90,96,100],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Facceptance_criteria_patterns.md","REFERENCE","参考文档",15278,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fspec-driven-workflow\u002Freferences\u002Facceptance_criteria_patterns.md",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fbounded_autonomy_rules.md",11607,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fspec-driven-workflow\u002Freferences\u002Fbounded_autonomy_rules.md",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fspec_format_guide.md",19127,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fspec-driven-workflow\u002Freferences\u002Fspec_format_guide.md",{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},"scripts\u002Fspec_generator.py","SCRIPT","脚本",10423,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fspec-driven-workflow\u002Fscripts\u002Fspec_generator.py",{"path":97,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":98,"sourceHtmlUrl":99},"scripts\u002Fspec_validator.py",17483,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fspec-driven-workflow\u002Fscripts\u002Fspec_validator.py",{"path":101,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":102,"sourceHtmlUrl":103},"scripts\u002Ftest_extractor.py",14890,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fengineering\u002Fspec-driven-workflow\u002Fscripts\u002Ftest_extractor.py",[105,134,159,182,212,232],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":114,"publishedAt":49},"01M6KC4E8MYR9DBAZTAXHKYMMH","soc2-compliance","Use when the user asks to prepare for SOC 2 audits, map Trust Service Criteria, build control matrices, collect audit evidence, perform gap analysis, or assess SOC 2 Type I vs Type II readiness.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fsoc2-compliance\u002FSKILL.md",[111],{"categoryNo":112,"categoryName":113,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000037","律师与法务",[115,116,117,118,119,120,121,122,41,123,124,125,126,127,128,129,130,131,132,133],"compliance","soc2","soc2 compliance","audit evidence","audit","collect","soc","analysis","evidence","trust","build","map","control","type","gap","readiness","gap analysis","assess","for",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":49},"01M6KC461R3GKGZ1TAYHVR1MW9","risk-management-specialist","Medical device risk management specialist implementing ISO 14971 throughout product lifecycle. Provides risk analysis, risk evaluation, risk control, and post-production information analysis. Use when user mentions risk management, ISO 14971, risk analysis, FMEA, fault tree analysis, hazard identification, risk control, risk matrix, benefit-risk analysis, residual risk, risk acceptability, or post-market risk.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Frisk-management-specialist\u002FSKILL.md",[],[141,142,143,144,145,146,147,148,122,41,149,150,151,152,153,154,155,156,157,158],"risk","risk management specialist","management","risk management","risk evaluation","product","Evaluation","lifecycle","risk matrix","iso","medical","iso 14971","identification","information","post-production","tree","matrix","implementing",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":49},"01M6KC3HF5ZFSSP2NZF68PEPFB","regulatory-affairs-head","Senior Regulatory Affairs Manager for HealthTech and MedTech companies. Prepares FDA 510(k), De Novo, and PMA submission packages; analyzes regulatory pathways for new medical devices; drafts responses to FDA deficiency letters and Notified Body queries; develops CE marking technical documentation under EU MDR 2017\u002F745; coordinates multi-market approval strategies across FDA, EU, Health Canada, PMDA, and NMPA; and maintains regulatory intelligence on evolving standards. Use when users need to plan or execute FDA submissions, navigate 510(k) or PMA approval processes, achieve CE marking, prepare pre-submission meeting materials, write regulatory strategy documents, respond to agency queries, or manage compliance documentation for medical device market access.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fregulatory-affairs-head\u002FSKILL.md",[],[166,167,168,169,170,171,38,39,172,41,173,174,175,176,177,178,179,180,181,133],"regulatory affairs head","regulatory","head","documents","devices","health","strategy","standards","queries","manage","strategies","de","users","respond","medical devices","manager",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":194,"publishedAt":49},"01M6KC34Z8M1559EY1CXYBJB1A","quality-manager-qms-iso13485","ISO 13485 Quality Management System implementation and maintenance for medical device organizations. Provides QMS design, documentation control, internal auditing, CAPA management, and certification support. Use when working with medical device quality systems, preparing for ISO 13485 audits, managing regulatory compliance documentation, setting up corrective actions, or building audit preparation programs. Useful for quality management, audit preparation, regulatory compliance, medical device documentation, and corrective action workflows.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-manager-qms-iso13485\u002FSKILL.md",[188,191],{"categoryNo":189,"categoryName":190,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":192,"categoryName":193,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[195,196,181,197,198,199,200,201,202,41,203,204,205,206,207,208,209,210,133,211],"quality manager qms iso13485","quality","design","workflows","validation","actions","certification","system","maintenance","document","systems","records","ISO 13485","organizations","corrective action","internal audit","preparation",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":219,"publishedAt":49},"01M6KC2FXHBHXYX2ZZ17Y3GDB4","quality-manager-qmr","Senior Quality Manager Responsible Person (QMR) for HealthTech and MedTech companies. Provides quality system governance, management review leadership, regulatory compliance oversight, and quality performance monitoring per ISO 13485 Clause 5.5.2.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-manager-qmr\u002FSKILL.md",[218],{"categoryNo":112,"categoryName":113,"taxonomyType":26,"taxonomyTypeDesc":27},[220,196,181,221,222,223,224,225,115,226,202,227,167,228,229,230,150,207,133,231],"quality manager qmr","review","policy","performance","governance","monitoring","regulatory compliance","oversight","cost","culture","leadership","person",{"skillNo":233,"name":234,"nameZh":6,"description":235,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":236,"categories":237,"keywords":243,"publishedAt":49},"01M6KC1VRR5JTDBNZANHPS6VR6","quality-documentation-manager","Document control system management for medical device QMS. Covers document numbering, version control, change management, and 21 CFR Part 11 compliance. Use for document control procedures, change control workflow, document numbering, version management, electronic signature compliance, or regulatory documentation review.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-documentation-manager\u002FSKILL.md",[238,241,242],{"categoryNo":239,"categoryName":240,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":112,"categoryName":113,"taxonomyType":26,"taxonomyTypeDesc":27},[244,245,196,181,221,29,246,119,202,247,248,249,250,251,151,252,253,254,255,133],"documentation","quality documentation manager","change","change management","list","master","system management","documentation review","cfr","21 cfr part 11","change control","retention"]