spec-driven-workflow

# Spec-Driven Workflow — POWERFUL

## Overview

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.

### Why Spec-First Matters

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.

### The Iron Law

```
NO CODE WITHOUT AN APPROVED SPEC.
NO EXCEPTIONS. NO "QUICK PROTOTYPES." NO "I'LL DOCUMENT IT LATER."
```

If the spec is not written, reviewed, and approved, implementation does not begin. Period.

---

## The Spec Format

Every spec follows this structure. No sections are optional — if a section does not apply, write "N/A — [reason]" so reviewers know it was considered, not forgotten.

### Mandatory Sections

| # | Section | Key Rules |
|---|---------|-----------|
| 1 | **Title and Metadata** | Author, date, status (Draft/In Review/Approved/Superseded), reviewers |
| 2 | **Context** | Why this feature exists. 2-4 paragraphs with evidence (metrics, tickets). |
| 3 | **Functional Requirements** | RFC 2119 keywords (MUST/SHOULD/MAY). Numbered FR-N. Each is atomic and testable. |
| 4 | **Non-Functional Requirements** | Performance, security, accessibility, scalability, reliability — all with measurable thresholds. |
| 5 | **Acceptance Criteria** | Given/When/Then format. Every AC references at least one FR-* or NFR-*. |
| 6 | **Edge Cases** | Numbered EC-N. Cover failure modes for every external dependency. |
| 7 | **API Contracts** | TypeScript-style interfaces. Cover success and error responses. |
| 8 | **Data Models** | Table format with field, type, constraints. Every entity from requirements must have a model. |
| 9 | **Out of Scope** | Explicit exclusions with reasons. Prevents scope creep during implementation. |

### RFC 2119 Keywords

| Keyword | Meaning |
|---------|---------|
| **MUST** | Absolute requirement. Non-conformant without it. |
| **MUST NOT** | Absolute prohibition. |
| **SHOULD** | Recommended. Omit only with documented justification. |
| **MAY** | Optional. Implementer's discretion. |

See [spec_format_guide.md](references/spec_format_guide.md) for the complete template with section-by-section examples, good/bad requirement patterns, and feature-type templates (CRUD, Integration, Migration).

See [acceptance_criteria_patterns.md](references/acceptance_criteria_patterns.md) for a full pattern library of Given/When/Then criteria across authentication, CRUD, search, file upload, payment, notification, and accessibility scenarios.

---

## Bounded Autonomy Rules

These rules define when an agent (human or AI) MUST stop and ask for guidance vs. when they can proceed independently.

### STOP and Ask When:

1. **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.

2. **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.

3. **Breaking changes required.** The implementation would change an existing API contract, database schema, or public interface. Always escalate.

4. **Security implications.** Any change that touches authentication, authorization, encryption, or PII handling requires explicit approval.

5. **Performance characteristics unknown.** If a requirement says "MUST complete in < 500ms" but you have no way to measure or guarantee that, escalate before implementing a guess.

6. **Cross-team dependencies.** If the spec requires coordination with another team or service, confirm the dependency before building against it.

### Continue Autonomously When:

1. **Spec is clear and unambiguous** for the current task.
2. **All acceptance criteria have passing tests** and you are refactoring internals.
3. **Changes are non-breaking** — no public API, schema, or behavior changes.
4. **Implementation is a direct translation** of a well-defined acceptance criterion.
5. **Error handling follows established patterns** already documented in the codebase.

### Escalation Protocol

When you must stop, provide:

```markdown
## Escalation: [Brief Title]

**Blocked on:** [requirement ID, e.g., FR-3]
**Question:** [Specific, answerable question — not "what should I do?"]
**Options considered:**
  A. [Option] — Pros: [...] Cons: [...]
  B. [Option] — Pros: [...] Cons: [...]
**My recommendation:** [A or B, with reasoning]
**Impact of waiting:** [What is blocked until this is resolved?]
```

Never escalate without a recommendation. Never present an open-ended question. Always give options.

See `references/bounded_autonomy_rules.md` for the complete decision matrix.

---

## Workflow — 6 Phases

### Phase 1: Gather Requirements

**Goal:** Understand what needs to be built and why.

1. **Interview the user.** Ask:
   - What problem does this solve?
   - Who are the users?
   - What does success look like?
   - What explicitly should NOT be built?
2. **Read existing code.** Understand the current system before proposing changes.
3. **Identify constraints.** Performance budgets, security requirements, backward compatibility.
4. **List unknowns.** Every unknown is a risk. Surface them now, not during implementation.

**Exit criteria:** You can explain the feature to someone unfamiliar with the project in 2 minutes.

### Phase 2: Write Spec

**Goal:** Produce a complete spec document following The Spec Format above.

1. Fill every section of the template. No section left blank.
2. Number all requirements (FR-*, NFR-*, AC-*, EC-*, OS-*).
3. Use RFC 2119 keywords precisely.
4. Write acceptance criteria in Given/When/Then format.
5. Define API contracts with TypeScript-style types.
6. List explicit exclusions in Out of Scope.

**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.

### Phase 3: Validate Spec

**Goal:** Verify the spec is complete, consistent, and implementable.

Run `spec_validator.py` against the spec file:

```bash
python spec_validator.py --file spec.md --strict
```

Manual validation checklist:
- [ ] Every functional requirement has at least one acceptance criterion
- [ ] Every acceptance criterion is testable (no subjective language)
- [ ] API contracts cover all endpoints mentioned in requirements
- [ ] Data models cover all entities mentioned in requirements
- [ ] Edge cases cover failure modes for every external dependency
- [ ] Out of scope is explicit about what was considered and rejected
- [ ] Non-functional requirements have measurable thresholds

**Exit criteria:** Spec scores 80+ on validator, and all manual checklist items pass.

### Phase 4: Generate Tests

**Goal:** Extract test cases from acceptance criteria before writing implementation code.

Run `test_extractor.py` against the approved spec:

```bash
python test_extractor.py --file spec.md --framework pytest --output tests/
```

1. Each acceptance criterion becomes one or more test cases.
2. Each edge case becomes a test case.
3. Tests are stubs — they define the assertion but not the implementation.
4. All tests MUST fail initially (red phase of TDD).

**Exit criteria:** You have a test file where every test fails with "not implemented" or equivalent.

### Phase 5: Implement

**Goal:** Write code that makes failing tests pass, one acceptance criterion at a time.

1. Pick one acceptance criterion (start with the simplest).
2. Make its test(s) pass with minimal code.
3. Run the full test suite — no regressions.
4. Commit.
5. Pick the next acceptance criterion. Repeat.

**Rules:**
- Do NOT implement anything not in the spec.
- Do NOT optimize before all acceptance criteria pass.
- Do NOT refactor before all acceptance criteria pass.
- If you discover a missing requirement, STOP and update the spec first.

**Exit criteria:** All tests pass. All acceptance criteria satisfied.

### Phase 6: Self-Review

**Goal:** Verify implementation matches spec before marking done.

Run through the Self-Review Checklist below. If any item fails, fix it before declaring the task complete.

---

## Self-Review Checklist

Before marking any implementation as done, verify ALL of the following:

- [ ] **Every acceptance criterion has a passing test.** No exceptions. If AC-3 exists, a test for AC-3 exists and passes.
- [ ] **Every edge case has a test.** EC-1 through EC-N all have corresponding test cases.
- [ ] **No scope creep.** The implementation does not include features not in the spec. If you added something, either update the spec or remove it.
- [ ] **API contracts match implementation.** Request/response shapes in code match the spec exactly. Field names, types, status codes — all of it.
- [ ] **Error scenarios tested.** Every error response defined in the spec has a test that triggers it.
- [ ] **Non-functional requirements verified.** If the spec says < 500ms, you have evidence (benchmark, load test, profiling) that it meets the threshold.
- [ ] **Data model matches.** Database schema matches the spec. No extra columns, no missing constraints.
- [ ] **Out-of-scope items not built.** Double-check that nothing from the Out of Scope section leaked into the implementation.

---

## Integration with TDD Guide

Spec-driven workflow and TDD are complementary, not competing:

```
Spec-Driven Workflow          TDD (Red-Green-Refactor)
─────────────────────         ──────────────────────────
Phase 1: Gather Requirements
Phase 2: Write Spec
Phase 3: Validate Spec
Phase 4: Generate Tests  ──→  RED: Tests exist and fail
Phase 5: Implement       ──→  GREEN: Minimal code to pass
Phase 6: Self-Review     ──→  REFACTOR: Clean up internals
```

**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.

Use `engineering-team/tdd-guide` for:
- Red-green-refactor cycle discipline
- Coverage analysis and gap detection
- Framework-specific test patterns (Jest, Pytest, JUnit)

Use `engineering/spec-driven-workflow` for:
- Defining what to build before building it
- Acceptance criteria authoring
- Completeness validation
- Scope control

---

## Examples

A complete worked example (Password Reset spec with extracted test cases) is available in [spec_format_guide.md](references/spec_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`.

---

## Anti-Patterns

### 1. Coding Before Spec Approval

**Symptom:** "I'll start coding while the spec is being reviewed."
**Problem:** The review will surface changes. Now you have code that implements a rejected design.
**Rule:** Implementation does not begin until spec status is "Approved."

### 2. Vague Acceptance Criteria

**Symptom:** "The system should work well" or "The UI should be responsive."
**Problem:** Untestable. What does "well" mean? What does "responsive" mean?
**Rule:** Every acceptance criterion must be verifiable by a machine. If you cannot write a test for it, rewrite the criterion.

### 3. Missing Edge Cases

**Symptom:** Happy path is specified, error paths are not.
**Problem:** Developers invent error handling on the fly, leading to inconsistent behavior.
**Rule:** For every external dependency (API, database, file system, user input), specify at least one failure scenario.

### 4. Spec as Post-Hoc Documentation

**Symptom:** "Let me write the spec now that the feature is done."
**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.
**Rule:** If the spec was written after the code, it is not a spec. Relabel it as documentation.

### 5. Gold-Plating Beyond Spec

**Symptom:** "While I was in there, I also added..."
**Problem:** Untested code. Unreviewed design. Potential for subtle bugs in the "bonus" feature.
**Rule:** If it is not in the spec, it does not get built. File a new spec for additional features.

### 6. Acceptance Criteria Without Requirement Traceability

**Symptom:** AC-7 exists but does not reference any FR-* or NFR-*.
**Problem:** Orphaned criteria mean either a requirement is missing or the criterion is unnecessary.
**Rule:** Every AC-* MUST reference at least one FR-* or NFR-*.

### 7. Skipping Validation

**Symptom:** "The spec looks fine, let's just start."
**Problem:** Missing sections discovered during implementation cause blocking delays.
**Rule:** Always run `spec_validator.py --strict` before starting implementation. Fix all warnings.

---

## Cross-References

- **`engineering-team/tdd-guide`** — Red-green-refactor cycle, test generation, coverage analysis. Use after Phase 4 of this workflow.
- **`engineering/focused-fix`** — Deep-dive feature repair. When a spec-driven implementation has systemic issues, use focused-fix for diagnosis.
- **`engineering/rag-architect`** — If the feature involves retrieval or knowledge systems, use rag-architect for the technical design within the spec.
- **`references/spec_format_guide.md`** — Complete template with section-by-section explanations.
- **`references/bounded_autonomy_rules.md`** — Full decision matrix for when to stop vs. continue.
- **`references/acceptance_criteria_patterns.md`** — Pattern library for writing Given/When/Then criteria.

---

## Tools

| Script | Purpose | Key Flags |
|--------|---------|-----------|
| `spec_generator.py` | Generate spec template from feature name/description | `--name`, `--description`, `--format`, `--json` |
| `spec_validator.py` | Validate spec completeness (0-100 score) | `--file`, `--strict`, `--json` |
| `test_extractor.py` | Extract test stubs from acceptance criteria | `--file`, `--framework`, `--output`, `--json` |

```bash
# Generate a spec template
python spec_generator.py --name "User Authentication" --description "OAuth 2.0 login flow"

# Validate a spec
python spec_validator.py --file specs/auth.md --strict

# Extract test cases
python test_extractor.py --file specs/auth.md --framework pytest --output tests/test_auth.py
```

{
  "format": "aiskill/v1",
  "skill": {
    "name": "spec-driven-workflow",
    "slug": "spec-driven-workflow",
    "version": "1.0.0",
    "description": "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.",
    "category": "Development",
    "tags": [
      "dev-workflow"
    ],
    "platforms": [
      "chatgpt",
      "claude-code",
      "cursor"
    ],
    "tested_environment": "Agent Skills convention (SKILL.md) — works with Claude Code, Cursor, ChatGPT/Codex and compatible agents",
    "license": "MIT"
  },
  "prompts": {
    "system": "# Spec-Driven Workflow — POWERFUL\r\n\r\n## Overview\r\n\r\nSpec-driven workflow enforces a single, non-negotiable rule: **write the specification BEFORE you write any code.** Not alongside. Not after. Before.\r\n\r\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.\r\n\r\n### Why Spec-First Matters\r\n\r\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.\r\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.\r\n3. **Enables parallelism.** Once a spec is approved, frontend, backend, QA, and documentation can all start simultaneously.\r\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.\r\n5. **Feeds TDD directly.** Acceptance criteria in Given/When/Then format translate 1:1 into test cases. The spec IS the test plan.\r\n\r\n### The Iron Law\r\n\r\n```\r\nNO CODE WITHOUT AN APPROVED SPEC.\r\nNO EXCEPTIONS. NO \"QUICK PROTOTYPES.\" NO \"I'LL DOCUMENT IT LATER.\"\r\n```\r\n\r\nIf the spec is not written, reviewed, and approved, implementation does not begin. Period.\r\n\r\n---\r\n\r\n## The Spec Format\r\n\r\nEvery spec follows this structure. No sections are optional — if a section does not apply, write \"N/A — [reason]\" so reviewers know it was considered, not forgotten.\r\n\r\n### Mandatory Sections\r\n\r\n| # | Section | Key Rules |\r\n|---|---------|-----------|\r\n| 1 | **Title and Metadata** | Author, date, status (Draft/In Review/Approved/Superseded), reviewers |\r\n| 2 | **Context** | Why this feature exists. 2-4 paragraphs with evidence (metrics, tickets). |\r\n| 3 | **Functional Requirements** | RFC 2119 keywords (MUST/SHOULD/MAY). Numbered FR-N. Each is atomic and testable. |\r\n| 4 | **Non-Functional Requirements** | Performance, security, accessibility, scalability, reliability — all with measurable thresholds. |\r\n| 5 | **Acceptance Criteria** | Given/When/Then format. Every AC references at least one FR-* or NFR-*. |\r\n| 6 | **Edge Cases** | Numbered EC-N. Cover failure modes for every external dependency. |\r\n| 7 | **API Contracts** | TypeScript-style interfaces. Cover success and error responses. |\r\n| 8 | **Data Models** | Table format with field, type, constraints. Every entity from requirements must have a model. |\r\n| 9 | **Out of Scope** | Explicit exclusions with reasons. Prevents scope creep during implementation. |\r\n\r\n### RFC 2119 Keywords\r\n\r\n| Keyword | Meaning |\r\n|---------|---------|\r\n| **MUST** | Absolute requirement. Non-conformant without it. |\r\n| **MUST NOT** | Absolute prohibition. |\r\n| **SHOULD** | Recommended. Omit only with documented justification. |\r\n| **MAY** | Optional. Implementer's discretion. |\r\n\r\nSee [spec_format_guide.md](references/spec_format_guide.md) for the complete template with section-by-section examples, good/bad requirement patterns, and feature-type templates (CRUD, Integration, Migration).\r\n\r\nSee [acceptance_criteria_patterns.md](references/acceptance_criteria_patterns.md) for a full pattern library of Given/When/Then criteria across authentication, CRUD, search, file upload, payment, notification, and accessibility scenarios.\r\n\r\n---\r\n\r\n## Bounded Autonomy Rules\r\n\r\nThese rules define when an agent (human or AI) MUST stop and ask for guidance vs. when they can proceed independently.\r\n\r\n### STOP and Ask When:\r\n\r\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.\r\n\r\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.\r\n\r\n3. **Breaking changes required.** The implementation would change an existing API contract, database schema, or public interface. Always escalate.\r\n\r\n4. **Security implications.** Any change that touches authentication, authorization, encryption, or PII handling requires explicit approval.\r\n\r\n5. **Performance characteristics unknown.** If a requirement says \"MUST complete in < 500ms\" but you have no way to measure or guarantee that, escalate before implementing a guess.\r\n\r\n6. **Cross-team dependencies.** If the spec requires coordination with another team or service, confirm the dependency before building against it.\r\n\r\n### Continue Autonomously When:\r\n\r\n1. **Spec is clear and unambiguous** for the current task.\r\n2. **All acceptance criteria have passing tests** and you are refactoring internals.\r\n3. **Changes are non-breaking** — no public API, schema, or behavior changes.\r\n4. **Implementation is a direct translation** of a well-defined acceptance criterion.\r\n5. **Error handling follows established patterns** already documented in the codebase.\r\n\r\n### Escalation Protocol\r\n\r\nWhen you must stop, provide:\r\n\r\n```markdown\r\n## Escalation: [Brief Title]\r\n\r\n**Blocked on:** [requirement ID, e.g., FR-3]\r\n**Question:** [Specific, answerable question — not \"what should I do?\"]\r\n**Options considered:**\r\n  A. [Option] — Pros: [...] Cons: [...]\r\n  B. [Option] — Pros: [...] Cons: [...]\r\n**My recommendation:** [A or B, with reasoning]\r\n**Impact of waiting:** [What is blocked until this is resolved?]\r\n```\r\n\r\nNever escalate without a recommendation. Never present an open-ended question. Always give options.\r\n\r\nSee `references/bounded_autonomy_rules.md` for the complete decision matrix.\r\n\r\n---\r\n\r\n## Workflow — 6 Phases\r\n\r\n### Phase 1: Gather Requirements\r\n\r\n**Goal:** Understand what needs to be built and why.\r\n\r\n1. **Interview the user.** Ask:\r\n   - What problem does this solve?\r\n   - Who are the users?\r\n   - What does success look like?\r\n   - What explicitly should NOT be built?\r\n2. **Read existing code.** Understand the current system before proposing changes.\r\n3. **Identify constraints.** Performance budgets, security requirements, backward compatibility.\r\n4. **List unknowns.** Every unknown is a risk. Surface them now, not during implementation.\r\n\r\n**Exit criteria:** You can explain the feature to someone unfamiliar with the project in 2 minutes.\r\n\r\n### Phase 2: Write Spec\r\n\r\n**Goal:** Produce a complete spec document following The Spec Format above.\r\n\r\n1. Fill every section of the template. No section left blank.\r\n2. Number all requirements (FR-*, NFR-*, AC-*, EC-*, OS-*).\r\n3. Use RFC 2119 keywords precisely.\r\n4. Write acceptance criteria in Given/When/Then format.\r\n5. Define API contracts with TypeScript-style types.\r\n6. List explicit exclusions in Out of Scope.\r\n\r\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.\r\n\r\n### Phase 3: Validate Spec\r\n\r\n**Goal:** Verify the spec is complete, consistent, and implementable.\r\n\r\nRun `spec_validator.py` against the spec file:\r\n\r\n```bash\r\npython spec_validator.py --file spec.md --strict\r\n```\r\n\r\nManual validation checklist:\r\n- [ ] Every functional requirement has at least one acceptance criterion\r\n- [ ] Every acceptance criterion is testable (no subjective language)\r\n- [ ] API contracts cover all endpoints mentioned in requirements\r\n- [ ] Data models cover all entities mentioned in requirements\r\n- [ ] Edge cases cover failure modes for every external dependency\r\n- [ ] Out of scope is explicit about what was considered and rejected\r\n- [ ] Non-functional requirements have measurable thresholds\r\n\r\n**Exit criteria:** Spec scores 80+ on validator, and all manual checklist items pass.\r\n\r\n### Phase 4: Generate Tests\r\n\r\n**Goal:** Extract test cases from acceptance criteria before writing implementation code.\r\n\r\nRun `test_extractor.py` against the approved spec:\r\n\r\n```bash\r\npython test_extractor.py --file spec.md --framework pytest --output tests/\r\n```\r\n\r\n1. Each acceptance criterion becomes one or more test cases.\r\n2. Each edge case becomes a test case.\r\n3. Tests are stubs — they define the assertion but not the implementation.\r\n4. All tests MUST fail initially (red phase of TDD).\r\n\r\n**Exit criteria:** You have a test file where every test fails with \"not implemented\" or equivalent.\r\n\r\n### Phase 5: Implement\r\n\r\n**Goal:** Write code that makes failing tests pass, one acceptance criterion at a time.\r\n\r\n1. Pick one acceptance criterion (start with the simplest).\r\n2. Make its test(s) pass with minimal code.\r\n3. Run the full test suite — no regressions.\r\n4. Commit.\r\n5. Pick the next acceptance criterion. Repeat.\r\n\r\n**Rules:**\r\n- Do NOT implement anything not in the spec.\r\n- Do NOT optimize before all acceptance criteria pass.\r\n- Do NOT refactor before all acceptance criteria pass.\r\n- If you discover a missing requirement, STOP and update the spec first.\r\n\r\n**Exit criteria:** All tests pass. All acceptance criteria satisfied.\r\n\r\n### Phase 6: Self-Review\r\n\r\n**Goal:** Verify implementation matches spec before marking done.\r\n\r\nRun through the Self-Review Checklist below. If any item fails, fix it before declaring the task complete.\r\n\r\n---\r\n\r\n## Self-Review Checklist\r\n\r\nBefore marking any implementation as done, verify ALL of the following:\r\n\r\n- [ ] **Every acceptance criterion has a passing test.** No exceptions. If AC-3 exists, a test for AC-3 exists and passes.\r\n- [ ] **Every edge case has a test.** EC-1 through EC-N all have corresponding test cases.\r\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.\r\n- [ ] **API contracts match implementation.** Request/response shapes in code match the spec exactly. Field names, types, status codes — all of it.\r\n- [ ] **Error scenarios tested.** Every error response defined in the spec has a test that triggers it.\r\n- [ ] **Non-functional requirements verified.** If the spec says < 500ms, you have evidence (benchmark, load test, profiling) that it meets the threshold.\r\n- [ ] **Data model matches.** Database schema matches the spec. No extra columns, no missing constraints.\r\n- [ ] **Out-of-scope items not built.** Double-check that nothing from the Out of Scope section leaked into the implementation.\r\n\r\n---\r\n\r\n## Integration with TDD Guide\r\n\r\nSpec-driven workflow and TDD are complementary, not competing:\r\n\r\n```\r\nSpec-Driven Workflow          TDD (Red-Green-Refactor)\r\n─────────────────────         ──────────────────────────\r\nPhase 1: Gather Requirements\r\nPhase 2: Write Spec\r\nPhase 3: Validate Spec\r\nPhase 4: Generate Tests  ──→  RED: Tests exist and fail\r\nPhase 5: Implement       ──→  GREEN: Minimal code to pass\r\nPhase 6: Self-Review     ──→  REFACTOR: Clean up internals\r\n```\r\n\r\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.\r\n\r\nUse `engineering-team/tdd-guide` for:\r\n- Red-green-refactor cycle discipline\r\n- Coverage analysis and gap detection\r\n- Framework-specific test patterns (Jest, Pytest, JUnit)\r\n\r\nUse `engineering/spec-driven-workflow` for:\r\n- Defining what to build before building it\r\n- Acceptance criteria authoring\r\n- Completeness validation\r\n- Scope control\r\n\r\n---\r\n\r\n## Examples\r\n\r\nA complete worked example (Password Reset spec with extracted test cases) is available in [spec_format_guide.md](references/spec_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`.\r\n\r\n---\r\n\r\n## Anti-Patterns\r\n\r\n### 1. Coding Before Spec Approval\r\n\r\n**Symptom:** \"I'll start coding while the spec is being reviewed.\"\r\n**Problem:** The review will surface changes. Now you have code that implements a rejected design.\r\n**Rule:** Implementation does not begin until spec status is \"Approved.\"\r\n\r\n### 2. Vague Acceptance Criteria\r\n\r\n**Symptom:** \"The system should work well\" or \"The UI should be responsive.\"\r\n**Problem:** Untestable. What does \"well\" mean? What does \"responsive\" mean?\r\n**Rule:** Every acceptance criterion must be verifiable by a machine. If you cannot write a test for it, rewrite the criterion.\r\n\r\n### 3. Missing Edge Cases\r\n\r\n**Symptom:** Happy path is specified, error paths are not.\r\n**Problem:** Developers invent error handling on the fly, leading to inconsistent behavior.\r\n**Rule:** For every external dependency (API, database, file system, user input), specify at least one failure scenario.\r\n\r\n### 4. Spec as Post-Hoc Documentation\r\n\r\n**Symptom:** \"Let me write the spec now that the feature is done.\"\r\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.\r\n**Rule:** If the spec was written after the code, it is not a spec. Relabel it as documentation.\r\n\r\n### 5. Gold-Plating Beyond Spec\r\n\r\n**Symptom:** \"While I was in there, I also added...\"\r\n**Problem:** Untested code. Unreviewed design. Potential for subtle bugs in the \"bonus\" feature.\r\n**Rule:** If it is not in the spec, it does not get built. File a new spec for additional features.\r\n\r\n### 6. Acceptance Criteria Without Requirement Traceability\r\n\r\n**Symptom:** AC-7 exists but does not reference any FR-* or NFR-*.\r\n**Problem:** Orphaned criteria mean either a requirement is missing or the criterion is unnecessary.\r\n**Rule:** Every AC-* MUST reference at least one FR-* or NFR-*.\r\n\r\n### 7. Skipping Validation\r\n\r\n**Symptom:** \"The spec looks fine, let's just start.\"\r\n**Problem:** Missing sections discovered during implementation cause blocking delays.\r\n**Rule:** Always run `spec_validator.py --strict` before starting implementation. Fix all warnings.\r\n\r\n---\r\n\r\n## Cross-References\r\n\r\n- **`engineering-team/tdd-guide`** — Red-green-refactor cycle, test generation, coverage analysis. Use after Phase 4 of this workflow.\r\n- **`engineering/focused-fix`** — Deep-dive feature repair. When a spec-driven implementation has systemic issues, use focused-fix for diagnosis.\r\n- **`engineering/rag-architect`** — If the feature involves retrieval or knowledge systems, use rag-architect for the technical design within the spec.\r\n- **`references/spec_format_guide.md`** — Complete template with section-by-section explanations.\r\n- **`references/bounded_autonomy_rules.md`** — Full decision matrix for when to stop vs. continue.\r\n- **`references/acceptance_criteria_patterns.md`** — Pattern library for writing Given/When/Then criteria.\r\n\r\n---\r\n\r\n## Tools\r\n\r\n| Script | Purpose | Key Flags |\r\n|--------|---------|-----------|\r\n| `spec_generator.py` | Generate spec template from feature name/description | `--name`, `--description`, `--format`, `--json` |\r\n| `spec_validator.py` | Validate spec completeness (0-100 score) | `--file`, `--strict`, `--json` |\r\n| `test_extractor.py` | Extract test stubs from acceptance criteria | `--file`, `--framework`, `--output`, `--json` |\r\n\r\n```bash\r\n# Generate a spec template\r\npython spec_generator.py --name \"User Authentication\" --description \"OAuth 2.0 login flow\"\r\n\r\n# Validate a spec\r\npython spec_validator.py --file specs/auth.md --strict\r\n\r\n# Extract test cases\r\npython test_extractor.py --file specs/auth.md --framework pytest --output tests/test_auth.py\r\n```",
    "user_template": ""
  },
  "variables": [],
  "install": {
    "steps": [
      {
        "title": "Download & unzip",
        "detail": "Download the .zip package from SkillVault and unzip it. The spec-driven-workflow/ folder contains SKILL.md plus any companion scripts, references and assets."
      },
      {
        "title": "Copy into your agent skills directory",
        "detail": "Move the folder into your agent's skills directory — e.g. ~/.claude/skills/ (Claude Code), .codex/skills/, .cursor/skills/ or your project's .claude/skills/ folder — then restart or reload the session."
      },
      {
        "title": "Use it",
        "detail": "Describe the task in natural language; the agent loads the skill automatically when the request matches the skill description."
      }
    ]
  },
  "usage": {
    "steps": []
  },
  "metadata": {
    "author": "SkillVault",
    "source": "https://skillvault.top/skills/spec-driven-workflow",
    "exported_at": "2026-11-03T07:42:11.166Z"
  }
}

format: aiskill/v1
skill:
  name: spec-driven-workflow
  slug: spec-driven-workflow
  version: 1.0.0
  description: >-
    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.
  category: Development
  tags:
    - dev-workflow
  platforms:
    - chatgpt
    - claude-code
    - cursor
  tested_environment: >-
    Agent Skills convention (SKILL.md) — works with Claude Code, Cursor, ChatGPT/Codex and
    compatible agents
  license: MIT
prompts:
  system: "# Spec-Driven Workflow — POWERFUL\r\n\r\n## Overview\r\n\r\nSpec-driven workflow enforces a single, non-negotiable rule: **write the specification BEFORE you write any code.** Not alongside. Not after. Before.\r\n\r\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.\r\n\r\n### Why Spec-First Matters\r\n\r\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.\r\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.\r\n3. **Enables parallelism.** Once a spec is approved, frontend, backend, QA, and documentation can all start simultaneously.\r\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.\r\n5. **Feeds TDD directly.** Acceptance criteria in Given/When/Then format translate 1:1 into test cases. The spec IS the test plan.\r\n\r\n### The Iron Law\r\n\r\n```\r\nNO CODE WITHOUT AN APPROVED SPEC.\r\nNO EXCEPTIONS. NO \"QUICK PROTOTYPES.\" NO \"I'LL DOCUMENT IT LATER.\"\r\n```\r\n\r\nIf the spec is not written, reviewed, and approved, implementation does not begin. Period.\r\n\r\n---\r\n\r\n## The Spec Format\r\n\r\nEvery spec follows this structure. No sections are optional — if a section does not apply, write \"N/A — [reason]\" so reviewers know it was considered, not forgotten.\r\n\r\n### Mandatory Sections\r\n\r\n| # | Section | Key Rules |\r\n|---|---------|-----------|\r\n| 1 | **Title and Metadata** | Author, date, status (Draft/In Review/Approved/Superseded), reviewers |\r\n| 2 | **Context** | Why this feature exists. 2-4 paragraphs with evidence (metrics, tickets). |\r\n| 3 | **Functional Requirements** | RFC 2119 keywords (MUST/SHOULD/MAY). Numbered FR-N. Each is atomic and testable. |\r\n| 4 | **Non-Functional Requirements** | Performance, security, accessibility, scalability, reliability — all with measurable thresholds. |\r\n| 5 | **Acceptance Criteria** | Given/When/Then format. Every AC references at least one FR-* or NFR-*. |\r\n| 6 | **Edge Cases** | Numbered EC-N. Cover failure modes for every external dependency. |\r\n| 7 | **API Contracts** | TypeScript-style interfaces. Cover success and error responses. |\r\n| 8 | **Data Models** | Table format with field, type, constraints. Every entity from requirements must have a model. |\r\n| 9 | **Out of Scope** | Explicit exclusions with reasons. Prevents scope creep during implementation. |\r\n\r\n### RFC 2119 Keywords\r\n\r\n| Keyword | Meaning |\r\n|---------|---------|\r\n| **MUST** | Absolute requirement. Non-conformant without it. |\r\n| **MUST NOT** | Absolute prohibition. |\r\n| **SHOULD** | Recommended. Omit only with documented justification. |\r\n| **MAY** | Optional. Implementer's discretion. |\r\n\r\nSee [spec_format_guide.md](references/spec_format_guide.md) for the complete template with section-by-section examples, good/bad requirement patterns, and feature-type templates (CRUD, Integration, Migration).\r\n\r\nSee [acceptance_criteria_patterns.md](references/acceptance_criteria_patterns.md) for a full pattern library of Given/When/Then criteria across authentication, CRUD, search, file upload, payment, notification, and accessibility scenarios.\r\n\r\n---\r\n\r\n## Bounded Autonomy Rules\r\n\r\nThese rules define when an agent (human or AI) MUST stop and ask for guidance vs. when they can proceed independently.\r\n\r\n### STOP and Ask When:\r\n\r\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.\r\n\r\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.\r\n\r\n3. **Breaking changes required.** The implementation would change an existing API contract, database schema, or public interface. Always escalate.\r\n\r\n4. **Security implications.** Any change that touches authentication, authorization, encryption, or PII handling requires explicit approval.\r\n\r\n5. **Performance characteristics unknown.** If a requirement says \"MUST complete in < 500ms\" but you have no way to measure or guarantee that, escalate before implementing a guess.\r\n\r\n6. **Cross-team dependencies.** If the spec requires coordination with another team or service, confirm the dependency before building against it.\r\n\r\n### Continue Autonomously When:\r\n\r\n1. **Spec is clear and unambiguous** for the current task.\r\n2. **All acceptance criteria have passing tests** and you are refactoring internals.\r\n3. **Changes are non-breaking** — no public API, schema, or behavior changes.\r\n4. **Implementation is a direct translation** of a well-defined acceptance criterion.\r\n5. **Error handling follows established patterns** already documented in the codebase.\r\n\r\n### Escalation Protocol\r\n\r\nWhen you must stop, provide:\r\n\r\n```markdown\r\n## Escalation: [Brief Title]\r\n\r\n**Blocked on:** [requirement ID, e.g., FR-3]\r\n**Question:** [Specific, answerable question — not \"what should I do?\"]\r\n**Options considered:**\r\n  A. [Option] — Pros: [...] Cons: [...]\r\n  B. [Option] — Pros: [...] Cons: [...]\r\n**My recommendation:** [A or B, with reasoning]\r\n**Impact of waiting:** [What is blocked until this is resolved?]\r\n```\r\n\r\nNever escalate without a recommendation. Never present an open-ended question. Always give options.\r\n\r\nSee `references/bounded_autonomy_rules.md` for the complete decision matrix.\r\n\r\n---\r\n\r\n## Workflow — 6 Phases\r\n\r\n### Phase 1: Gather Requirements\r\n\r\n**Goal:** Understand what needs to be built and why.\r\n\r\n1. **Interview the user.** Ask:\r\n   - What problem does this solve?\r\n   - Who are the users?\r\n   - What does success look like?\r\n   - What explicitly should NOT be built?\r\n2. **Read existing code.** Understand the current system before proposing changes.\r\n3. **Identify constraints.** Performance budgets, security requirements, backward compatibility.\r\n4. **List unknowns.** Every unknown is a risk. Surface them now, not during implementation.\r\n\r\n**Exit criteria:** You can explain the feature to someone unfamiliar with the project in 2 minutes.\r\n\r\n### Phase 2: Write Spec\r\n\r\n**Goal:** Produce a complete spec document following The Spec Format above.\r\n\r\n1. Fill every section of the template. No section left blank.\r\n2. Number all requirements (FR-*, NFR-*, AC-*, EC-*, OS-*).\r\n3. Use RFC 2119 keywords precisely.\r\n4. Write acceptance criteria in Given/When/Then format.\r\n5. Define API contracts with TypeScript-style types.\r\n6. List explicit exclusions in Out of Scope.\r\n\r\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.\r\n\r\n### Phase 3: Validate Spec\r\n\r\n**Goal:** Verify the spec is complete, consistent, and implementable.\r\n\r\nRun `spec_validator.py` against the spec file:\r\n\r\n```bash\r\npython spec_validator.py --file spec.md --strict\r\n```\r\n\r\nManual validation checklist:\r\n- [ ] Every functional requirement has at least one acceptance criterion\r\n- [ ] Every acceptance criterion is testable (no subjective language)\r\n- [ ] API contracts cover all endpoints mentioned in requirements\r\n- [ ] Data models cover all entities mentioned in requirements\r\n- [ ] Edge cases cover failure modes for every external dependency\r\n- [ ] Out of scope is explicit about what was considered and rejected\r\n- [ ] Non-functional requirements have measurable thresholds\r\n\r\n**Exit criteria:** Spec scores 80+ on validator, and all manual checklist items pass.\r\n\r\n### Phase 4: Generate Tests\r\n\r\n**Goal:** Extract test cases from acceptance criteria before writing implementation code.\r\n\r\nRun `test_extractor.py` against the approved spec:\r\n\r\n```bash\r\npython test_extractor.py --file spec.md --framework pytest --output tests/\r\n```\r\n\r\n1. Each acceptance criterion becomes one or more test cases.\r\n2. Each edge case becomes a test case.\r\n3. Tests are stubs — they define the assertion but not the implementation.\r\n4. All tests MUST fail initially (red phase of TDD).\r\n\r\n**Exit criteria:** You have a test file where every test fails with \"not implemented\" or equivalent.\r\n\r\n### Phase 5: Implement\r\n\r\n**Goal:** Write code that makes failing tests pass, one acceptance criterion at a time.\r\n\r\n1. Pick one acceptance criterion (start with the simplest).\r\n2. Make its test(s) pass with minimal code.\r\n3. Run the full test suite — no regressions.\r\n4. Commit.\r\n5. Pick the next acceptance criterion. Repeat.\r\n\r\n**Rules:**\r\n- Do NOT implement anything not in the spec.\r\n- Do NOT optimize before all acceptance criteria pass.\r\n- Do NOT refactor before all acceptance criteria pass.\r\n- If you discover a missing requirement, STOP and update the spec first.\r\n\r\n**Exit criteria:** All tests pass. All acceptance criteria satisfied.\r\n\r\n### Phase 6: Self-Review\r\n\r\n**Goal:** Verify implementation matches spec before marking done.\r\n\r\nRun through the Self-Review Checklist below. If any item fails, fix it before declaring the task complete.\r\n\r\n---\r\n\r\n## Self-Review Checklist\r\n\r\nBefore marking any implementation as done, verify ALL of the following:\r\n\r\n- [ ] **Every acceptance criterion has a passing test.** No exceptions. If AC-3 exists, a test for AC-3 exists and passes.\r\n- [ ] **Every edge case has a test.** EC-1 through EC-N all have corresponding test cases.\r\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.\r\n- [ ] **API contracts match implementation.** Request/response shapes in code match the spec exactly. Field names, types, status codes — all of it.\r\n- [ ] **Error scenarios tested.** Every error response defined in the spec has a test that triggers it.\r\n- [ ] **Non-functional requirements verified.** If the spec says < 500ms, you have evidence (benchmark, load test, profiling) that it meets the threshold.\r\n- [ ] **Data model matches.** Database schema matches the spec. No extra columns, no missing constraints.\r\n- [ ] **Out-of-scope items not built.** Double-check that nothing from the Out of Scope section leaked into the implementation.\r\n\r\n---\r\n\r\n## Integration with TDD Guide\r\n\r\nSpec-driven workflow and TDD are complementary, not competing:\r\n\r\n```\r\nSpec-Driven Workflow          TDD (Red-Green-Refactor)\r\n─────────────────────         ──────────────────────────\r\nPhase 1: Gather Requirements\r\nPhase 2: Write Spec\r\nPhase 3: Validate Spec\r\nPhase 4: Generate Tests  ──→  RED: Tests exist and fail\r\nPhase 5: Implement       ──→  GREEN: Minimal code to pass\r\nPhase 6: Self-Review     ──→  REFACTOR: Clean up internals\r\n```\r\n\r\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.\r\n\r\nUse `engineering-team/tdd-guide` for:\r\n- Red-green-refactor cycle discipline\r\n- Coverage analysis and gap detection\r\n- Framework-specific test patterns (Jest, Pytest, JUnit)\r\n\r\nUse `engineering/spec-driven-workflow` for:\r\n- Defining what to build before building it\r\n- Acceptance criteria authoring\r\n- Completeness validation\r\n- Scope control\r\n\r\n---\r\n\r\n## Examples\r\n\r\nA complete worked example (Password Reset spec with extracted test cases) is available in [spec_format_guide.md](references/spec_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`.\r\n\r\n---\r\n\r\n## Anti-Patterns\r\n\r\n### 1. Coding Before Spec Approval\r\n\r\n**Symptom:** \"I'll start coding while the spec is being reviewed.\"\r\n**Problem:** The review will surface changes. Now you have code that implements a rejected design.\r\n**Rule:** Implementation does not begin until spec status is \"Approved.\"\r\n\r\n### 2. Vague Acceptance Criteria\r\n\r\n**Symptom:** \"The system should work well\" or \"The UI should be responsive.\"\r\n**Problem:** Untestable. What does \"well\" mean? What does \"responsive\" mean?\r\n**Rule:** Every acceptance criterion must be verifiable by a machine. If you cannot write a test for it, rewrite the criterion.\r\n\r\n### 3. Missing Edge Cases\r\n\r\n**Symptom:** Happy path is specified, error paths are not.\r\n**Problem:** Developers invent error handling on the fly, leading to inconsistent behavior.\r\n**Rule:** For every external dependency (API, database, file system, user input), specify at least one failure scenario.\r\n\r\n### 4. Spec as Post-Hoc Documentation\r\n\r\n**Symptom:** \"Let me write the spec now that the feature is done.\"\r\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.\r\n**Rule:** If the spec was written after the code, it is not a spec. Relabel it as documentation.\r\n\r\n### 5. Gold-Plating Beyond Spec\r\n\r\n**Symptom:** \"While I was in there, I also added...\"\r\n**Problem:** Untested code. Unreviewed design. Potential for subtle bugs in the \"bonus\" feature.\r\n**Rule:** If it is not in the spec, it does not get built. File a new spec for additional features.\r\n\r\n### 6. Acceptance Criteria Without Requirement Traceability\r\n\r\n**Symptom:** AC-7 exists but does not reference any FR-* or NFR-*.\r\n**Problem:** Orphaned criteria mean either a requirement is missing or the criterion is unnecessary.\r\n**Rule:** Every AC-* MUST reference at least one FR-* or NFR-*.\r\n\r\n### 7. Skipping Validation\r\n\r\n**Symptom:** \"The spec looks fine, let's just start.\"\r\n**Problem:** Missing sections discovered during implementation cause blocking delays.\r\n**Rule:** Always run `spec_validator.py --strict` before starting implementation. Fix all warnings.\r\n\r\n---\r\n\r\n## Cross-References\r\n\r\n- **`engineering-team/tdd-guide`** — Red-green-refactor cycle, test generation, coverage analysis. Use after Phase 4 of this workflow.\r\n- **`engineering/focused-fix`** — Deep-dive feature repair. When a spec-driven implementation has systemic issues, use focused-fix for diagnosis.\r\n- **`engineering/rag-architect`** — If the feature involves retrieval or knowledge systems, use rag-architect for the technical design within the spec.\r\n- **`references/spec_format_guide.md`** — Complete template with section-by-section explanations.\r\n- **`references/bounded_autonomy_rules.md`** — Full decision matrix for when to stop vs. continue.\r\n- **`references/acceptance_criteria_patterns.md`** — Pattern library for writing Given/When/Then criteria.\r\n\r\n---\r\n\r\n## Tools\r\n\r\n| Script | Purpose | Key Flags |\r\n|--------|---------|-----------|\r\n| `spec_generator.py` | Generate spec template from feature name/description | `--name`, `--description`, `--format`, `--json` |\r\n| `spec_validator.py` | Validate spec completeness (0-100 score) | `--file`, `--strict`, `--json` |\r\n| `test_extractor.py` | Extract test stubs from acceptance criteria | `--file`, `--framework`, `--output`, `--json` |\r\n\r\n```bash\r\n# Generate a spec template\r\npython spec_generator.py --name \"User Authentication\" --description \"OAuth 2.0 login flow\"\r\n\r\n# Validate a spec\r\npython spec_validator.py --file specs/auth.md --strict\r\n\r\n# Extract test cases\r\npython test_extractor.py --file specs/auth.md --framework pytest --output tests/test_auth.py\r\n```"
  user_template: ""
variables: []
install:
  steps:
    - title: Download & unzip
      detail: >-
        Download the .zip package from SkillVault and unzip it. The spec-driven-workflow/ folder
        contains SKILL.md plus any companion scripts, references and assets.
    - title: Copy into your agent skills directory
      detail: >-
        Move the folder into your agent's skills directory — e.g. ~/.claude/skills/ (Claude Code),
        .codex/skills/, .cursor/skills/ or your project's .claude/skills/ folder — then restart or
        reload the session.
    - title: Use it
      detail: >-
        Describe the task in natural language; the agent loads the skill automatically when the
        request matches the skill description.
usage:
  steps: []
metadata:
  author: SkillVault
  source: https://skillvault.top/skills/spec-driven-workflow
  exported_at: "2026-11-03T07:42:11.166Z"