5d-sdd
5D Spec-Driven Development - A complete methodology for building software through structured phases. Use when: (1) User wants to build something non-trivial, (2) User mentions '5D' or 'spec-driven development,' (3) Starting a new project or feature that needs careful planning, (4) User wants a structured approach to development. This skill orchestrates the full workflow across 10 phases from orientation to reflection.
SKILL.md
| Name | 5d-sdd |
| Description | 5D Spec-Driven Development - A complete methodology for building software through structured phases. Use when: (1) User wants to build something non-trivial, (2) User mentions '5D' or 'spec-driven development,' (3) Starting a new project or feature that needs careful planning, (4) User wants a structured approach to development. This skill orchestrates the full workflow across 10 phases from orientation to reflection. |
name: 5d-sdd description: "5D Spec-Driven Development - A complete methodology for building software through structured phases. Use when: (1) User wants to build something non-trivial, (2) User mentions '5D' or 'spec-driven development,' (3) Starting a new project or feature that needs careful planning, (4) User wants a structured approach to development. This skill orchestrates the full workflow across 10 phases from orientation to reflection." user-invocable: true
5D Spec-Driven Development
A methodology for building software that prevents wasted effort by ensuring understanding before commitment at every level.
Core Philosophy
The 5 Dimensions
- Width - Multiple domains (technical, business, user, ops, design)
- Depth - Thinking levels (reactive → dogmatic → integrative → creative)
- Height - Skill dependencies (what capabilities enable other capabilities)
- Quadrants - Four perspectives (Individual/Collective × Inner/Outer)
- Time - Evolution ("transcend and include" from current state)
Why This Exists
Most development failures come from:
- Building before understanding
- Single-perspective thinking
- Hidden assumptions
- Spec drift from intent
- No feedback loops
5D-SDD addresses each through structured phases with explicit exit criteria.
The 10 Phases
UNDERSTAND DESIGN BUILD LEARN
─────────────── ─────────────── ─────────────── ───────────
0. ORIENT 2. PLAN 6. TASKS 9. REFLECT
1. SPAR 3. REFINE 7. BUILD
4. SPEC 8. VERIFY
5. GAP ANALYSIS
Phase Overview
| # | Phase | Skill | What Happens | Output |
|---|---|---|---|---|
| 0 | ORIENT | 5d-orient | Map domains, surface assumptions | Orientation Summary |
| 1 | SPAR | 5d-spar | Challenge thinking, find blind spots | SPAR Summary |
| 2 | PLAN | 5d-plan | Crystallize into concrete plan | PLAN.md |
| 3 | REFINE | 5d-refine | Stress-test, probe edge cases | Refinement Summary |
| 4 | SPEC | 5d-spec | Formalize technical specification | SPEC.md |
| 5 | GAP | 5d-gap-analysis | Identify all required changes | Gap Analysis |
| 6 | TASKS | 5d-tasks | Sequence into executable tasks | Task List |
| 7 | BUILD | 5d-build | Implement with spec fidelity | Working code |
| 8 | VERIFY | 5d-verify | Multi-layer verification | Verification Report |
| 9 | REFLECT | 5d-reflect | Extract learning | Retrospective |
How to Use
Full Workflow
For new features or projects, run phases sequentially:
/5d-orient → /5d-spar → /5d-plan → /5d-refine → /5d-spec → /5d-gap-analysis → /5d-tasks → /5d-build → /5d-verify → /5d-reflect
Each phase has exit criteria. Don't proceed until criteria are met.
Partial Workflows
Use individual phases when appropriate:
| Scenario | Start At |
|---|---|
| "I have an idea, let's explore it" | ORIENT |
| "I know what I want, challenge my thinking" | SPAR |
| "We've discussed enough, write the plan" | PLAN |
| "Review this plan for issues" | REFINE |
| "Turn this plan into a technical spec" | SPEC |
| "What do we need to change?" | GAP ANALYSIS |
| "Break this into tasks" | TASKS |
| "Implement this task" | BUILD |
| "Check if this is working" | VERIFY |
| "What did we learn?" | REFLECT |
Failure Routing
When something fails, return to the appropriate phase:
| Failure Type | Return To |
|---|---|
| Code doesn't run | BUILD |
| Works but wrong output | BUILD or SPEC |
| Works but users confused | PLAN |
| Solves wrong problem | SPAR or ORIENT |
| Keeps failing despite fixes | Earlier phase (assumptions wrong) |
Key Principles
1. No Commitment Without Understanding
Each phase deepens understanding before the next commitment:
- ORIENT → understand the space
- SPAR → understand objections
- PLAN → commit to direction
- REFINE → understand risks
- SPEC → commit to implementation
- BUILD → commit to code
2. Multi-Perspective Thinking
Every phase checks multiple quadrants:
| Quadrant | Focus |
|---|---|
| Individual Outer | What artifacts exist? |
| Individual Inner | What understanding is needed? |
| Collective Outer | What systems/constraints exist? |
| Collective Inner | What alignment is needed? |
3. Explicit Over Implicit
- Document assumptions, don't hide them
- Document alternatives considered
- Document what's explicitly out of scope
- Make bets visible
4. Fail Fast, Route Correctly
- Do risky/unknown work early
- When something fails, identify which layer
- Return to the right phase, don't patch at the wrong level
5. Identity Trap Awareness
Why thinking stops: Latching onto ideas as identity. When identity is threatened, the mind defends rather than explores.
Signs of the trap:
- Dismissing objections without examination
- Adding complexity to protect core assumptions
- "That won't happen" without evidence
- Rushing past uncomfortable phases
Counteract by:
- Notice when you feel defensive—probe there
- Hold positions lightly
- Ask: "What would make me wrong?"
Quick Reference
Starting a New Feature
- User describes what they want
- Run ORIENT to map the space
- Run SPAR to challenge assumptions
- Run PLAN to crystallize direction
- Run REFINE to stress-test
- Run SPEC to formalize
- Run GAP ANALYSIS to scope work
- Run TASKS to sequence
- Run BUILD for each task
- Run VERIFY when batch complete
- Run REFLECT at iteration end
Documents Produced
PLAN.md- What we're building and whySPEC.md- How we're building it technically- Task list - Sequenced implementation steps
- Verification report - What passed/failed
- Retrospective - What we learned
When to Skip Phases
- Trivial changes: Skip to BUILD
- Already planned: Start at SPEC or GAP ANALYSIS
- Bug fixes: Start at BUILD, but VERIFY thoroughly
- Exploratory work: ORIENT and SPAR only
Never skip VERIFY. Always close the loop.