[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-1a068064-68b0-4e1c-9a7f-02a0d3044780":3,"$fBACI50gDTCmsjNz2Fv4e9ua4RSzbpDgPRnkSIEs_PpY":43},{"id":4,"title":5,"description":6,"categoryId":7,"moduleId":8,"tags":9,"prompt":10,"icon":11,"source":12,"sourceUrl":13,"authorId":14,"authorName":15,"isPublic":16,"stars":17,"runs":18,"createdAt":19,"updatedAt":19,"module":20,"category":27,"packages":34},"1a068064-68b0-4e1c-9a7f-02a0d3044780","spec-driven-workflow","使用于用户要求在编写代码之前编写规范、定义验收标准、在实施之前规划功能、从规范生成测试或遵循先规范后开发实践时。","cat_prod_automation","mod_productivity","alirezarezvani,productivity","---\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","","imported","https:\u002F\u002Fgithub.com\u002Falirezarezvani\u002Fclaude-skills","user_system_seed","SkillOPIC",true,192,366,"2026-05-16 13:55:35",{"id":8,"name":21,"slug":22,"icon":23,"description":24,"sort":25,"createdAt":26},"效率工具","productivity","mdi-lightning-bolt-outline","文档处理、数据分析、自动化工作流",4,"2026-05-16 12:53:40",{"id":7,"name":28,"slug":29,"icon":30,"description":31,"moduleId":8,"sort":32,"skillCount":33,"createdAt":26},"自动化","automation","mdi-robot-outline","工作流自动化、批处理",3,101,[35],{"id":36,"skillId":4,"version":37,"fileName":38,"fileSize":39,"filePath":40,"fileHash":41,"manifest":42,"createdAt":19},"9a6b808f-e002-4ab8-89c5-488de162c93c","1.0.0","spec-driven-workflow.zip",35717,"uploads\u002Fskills\u002F1a068064-68b0-4e1c-9a7f-02a0d3044780\u002Fspec-driven-workflow.zip","31009a1253ffef7f824205c517fabffd08b60e92f79d3f440d6dd076cd4e7f2c","[{\"path\":\"SKILL.md\",\"isDirectory\":false,\"size\":15646},{\"path\":\"references\u002Facceptance_criteria_patterns.md\",\"isDirectory\":false,\"size\":15278},{\"path\":\"references\u002Fbounded_autonomy_rules.md\",\"isDirectory\":false,\"size\":11607},{\"path\":\"references\u002Fspec_format_guide.md\",\"isDirectory\":false,\"size\":19127},{\"path\":\"scripts\u002Fspec_generator.py\",\"isDirectory\":false,\"size\":10423},{\"path\":\"scripts\u002Fspec_validator.py\",\"isDirectory\":false,\"size\":17483},{\"path\":\"scripts\u002Ftest_extractor.py\",\"isDirectory\":false,\"size\":14890}]",{"code":44,"message":45,"data":46},200,"success",{"items":47,"stats":48,"page":51},[],{"averageRating":49,"totalRatings":49,"ratingCounts":50},0,[49,49,49,49,49],{"limit":52,"offset":49,"hasMore":53,"nextOffset":52,"ratedOnly":16},15,false]