Spec-Driven Development with Claude Skills: Ship Features Faster

Most feature development fails not during coding — it fails before a single line is written. Vague requirements, missed dependencies, and absent quality criteria are decided by whoever types the first git commit, often under deadline pressure. Spec-Driven Development (SDD) fixes this by making the specification the primary artifact, with code becoming a generated output.

This guide shows how a curated set of Claude Skills implements the full SDD cycle: from raw idea to reviewed pull request, with structured handoffs at every stage.

What Is Spec-Driven Development?

SDD separates the cognitive work of deciding what to build from the mechanical work of building it. A feature passes through three explicit phases:

1. Brainstorm — explore the solution space; surface tradeoffs before committing.
2. Plan — produce a formal spec: architecture decisions, file-level task breakdown, parallelization strategy, and verification criteria.
3. Implement — execute against the spec with automated checkpoints and quality gates.

The productivity gain is not from moving faster in any single phase. It comes from eliminating the constant context-switching between design and implementation that degrades both. When Claude implements against an approved spec, it has no ambiguity to resolve by guessing — and you are not interrupted to make decisions that should have been made two hours earlier.

Thoughtworks noted in 2025 that SDD was one of the year's most significant new AI-assisted engineering practices, citing reduced approval overhead and more predictable delivery cycles as the core benefits.

The Four-Skill Pipeline

Step 1 — Analyze the Issue with git-analyze-issue

Most features start as a GitHub Issue, a Slack thread, or a Jira ticket — not a clean spec. The git-analyze-issue skill bridges that gap.

Point it at any open issue and it produces a structured technical spec document covering:

• Problem statement and acceptance criteria extracted from issue text and comments
• Technical approach options ranked by complexity
• Implementation plan with estimated scope
• Testing strategy aligned to the proposed changes

This output becomes the input for the brainstorm phase. The skill reads repository context automatically, so its architecture recommendations are grounded in your actual codebase — not generic advice.

Step 2 — Explore Solutions with sdd-brainstorm

The sdd-brainstorm skill takes a problem statement — from git-analyze-issue or written directly — and runs a structured ideation session.

It always generates exactly six solutions: three high-probability approaches that follow established patterns in your stack, and three exploratory approaches that may involve different abstractions, third-party integrations, or architectural shifts. For each solution it provides:

• A one-paragraph rationale
• Key tradeoffs (complexity, performance, maintainability)
• Risks and open questions
• A recommendation on when this approach is appropriate

The skill then asks targeted clarifying questions before finalizing. The output is not a winner — it is a structured comparison that lets you make an informed choice. The distinction matters: Claude is surfacing the option space, not collapsing it prematurely.

Example invocation:

# In your project with sdd-brainstorm installed
claude "Use sdd-brainstorm to explore approaches for adding real-time collaboration
to our document editor. Current stack: Next.js, PostgreSQL, Redis."

Claude will analyze the existing codebase structure, then present six concrete implementation strategies ranging from WebSocket-based CRDT to operational transform with Yjs, each scoped to your actual infrastructure.

Step 3 — Build the Task Spec with sdd-plan

Once you have chosen a direction, sdd-plan transforms that decision into an implementation-ready spec through a six-stage refinement pipeline:

1. Parallel analysis — Claude spawns sub-agents to analyze architecture, dependencies, and testing requirements simultaneously.
2. Architecture synthesis — findings are merged into a coherent technical approach.
3. Task decomposition — the implementation is broken into discrete, independently-verifiable tasks with file-level specificity (which files to create, which functions to modify, in what order).
4. Parallelization planning — tasks are grouped by dependency so independent work can run concurrently.
5. Verification criteria — each task gets explicit pass/fail conditions that the implementation phase can check automatically.
6. Quality gate promotion — the spec is marked ready only when all criteria are internally consistent.

The spec produced by sdd-plan is a Markdown document, typically 200–500 lines, that can be reviewed by your team before implementation begins. This is the checkpoint where human judgment is most valuable — not mid-implementation when context has been lost.

Step 4 — Implement with Checkpoints via sdd-implement

sdd-implement executes against the approved spec. It differs from naive "write the code" prompts in three important ways:

LLM-as-Judge verification. After completing each task in the spec, Claude evaluates its own output against the verification criteria defined in the plan phase. Tasks that fail verification trigger an automatic repair loop before proceeding. This catches the most common class of implementation drift — where code compiles and passes linting but violates a logical constraint defined in the spec.

Breakpoint resume. If a long implementation run is interrupted (network drop, context limit, user abort), sdd-implement resumes from the last verified checkpoint rather than restarting. For features that span dozens of files, this is the difference between a recoverable interruption and a wasted hour.

Human-in-the-loop gates. The spec can designate certain decisions as human checkpoints — moments where Claude will pause and present options rather than choosing autonomously. Architecture choices that affect multiple teams, decisions with non-obvious security implications, or any task marked REVIEW_REQUIRED in the spec will trigger a pause.

# Install the full SDD pipeline
mkdir -p .claude/skills
gh release download --repo your-org/sdd-skills --pattern "*.zip" --dir /tmp/sdd
cp /tmp/sdd/sdd-brainstorm.md .claude/skills/
cp /tmp/sdd/sdd-plan.md .claude/skills/
cp /tmp/sdd/sdd-implement.md .claude/skills/

Integrating SDD with Your Git Workflow

The SDD pipeline produces clean commit boundaries by design. Each verified task in the implementation spec corresponds to a logical unit of change — which maps naturally to conventional commits.

After implementation, the git-create-pr skill handles PR creation: it checks for uncommitted changes, formats the PR description with the context from the spec, and applies conventional commit conventions with appropriate emoji markers.

For code review before the PR is opened, the review-local-changes skill runs six specialized review agents in parallel — covering security, bug detection, code quality, API contracts, test coverage, and change history — then aggregates findings with confidence scoring and false-positive filtering. The multi-agent approach catches issues that single-pass review consistently misses, particularly in the interaction between security and API contract constraints.

A full SDD cycle for a medium-complexity feature typically looks like this:

1. Issue created in GitHub
2. git-analyze-issue → structured technical spec doc
3. sdd-brainstorm → six solution approaches presented
4. Team reviews brainstorm, selects approach (5 minutes)
5. sdd-plan → implementation spec with verification criteria
6. Team reviews spec, approves (10 minutes)
7. sdd-implement → code produced with auto-verification
8. review-local-changes → multi-agent review report
9. git-create-pr → PR opened with spec-grounded description
10. Reviewer merges

Steps 3–9 can complete in under an hour for features that would have taken a day of back-and-forth under traditional workflows.

When SDD Is — and Isn't — the Right Fit

SDD adds most value when:

• The feature touches multiple subsystems or teams
• Requirements are genuinely ambiguous at the start
• The implementation will be reviewed by engineers who weren't in the initial design conversation
• You need an auditable record of why architectural decisions were made

SDD adds less value for:

• Hotfixes where the cause and solution are already known
• Exploratory spikes intended to be thrown away
• Single-file changes with no cross-system dependencies

The skills are independently useful — using sdd-brainstorm alone for a design discussion, or sdd-plan alone to structure an existing idea, is entirely valid. The full pipeline is not a requirement.

Get Started

All four skills in this workflow are available on Claude Skills Hub:

• git-analyze-issue — turn GitHub Issues into technical specs
• sdd-brainstorm — explore the solution space before committing
• sdd-plan — produce implementation-ready task specs with quality gates
• sdd-implement — execute with auto-verification and human checkpoints

Download any skill as a ZIP, unpack into .claude/skills/ in your project root, and Claude Code will load it automatically on the next session start.

The goal of SDD is not to remove engineers from the loop — it is to ensure the loop runs at the right level of abstraction. Decisions belong in the spec. Execution belongs in the implementation. Claude Skills make that separation practical.