How do I install the Spec Driven Development skill?

Run npx skillmds@latest add hi-donwi/spec-driven-development in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Spec Driven Development safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Spec Driven Development?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Spec Driven Development free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Spec Driven Development?

hi-donwi (@hi-donwi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Spec Driven Development by hi-donwi

Name: Spec Driven Development
Rating: 4.2 (5 reviews)
Author: hi-donwi

Spec Driven Development

Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Do not use when a spec already exists, or for small bugfixes that do not change intended behaviour.

hi-donwi Updated Sep 22, 2026

File contents

Spec-Driven Development

Overview

Write a structured specification before writing any code. The spec is the shared source of truth between you and the human engineer — it defines what we're building, why, and how we'll know it's done. Code without a spec is guessing.

When to use

Starting a new project or feature
Requirements are ambiguous or incomplete
The change touches multiple files or modules
You're about to make an architectural decision
The task would take more than 30 minutes to implement

Do not use for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. If a spec already exists, do not write another — implement against it.

Process

Do not advance a phase until the current one is validated:

SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT

Specify. Surface assumptions first. Cover objective, commands, project structure, code style, testing strategy, and boundaries (Always / Ask first / Never). Reframe vague requirements as testable success criteria. Spec template: references/spec-template.md.
Plan. Components, order, risks, parallel vs sequential, checkpoints. Canonical slicing lives in planning-and-task-breakdown. Save tasks/plan.md and tasks/todo.md.
Tasks. One focused session each, with acceptance criteria, verification, ≤ ~5 files, ordered by dependency.
Implement with incremental-implementation and test-driven-development. Load the right spec sections via context-engineering.
Keep the spec alive. Update it when decisions or scope change; commit it; link it from PRs.

Red flags

Starting to write code without any written requirements
Asking "should I just start building?" before clarifying what "done" means
Implementing features not mentioned in any spec or task list
Making architectural decisions without documenting them
Skipping the spec because "it's obvious what to build"

Verification

Before proceeding to implementation, confirm:

The spec covers all six core areas
The human has reviewed and approved the spec
Success criteria are specific and testable
Boundaries (Always/Ask First/Never) are defined
The spec is saved to a file in the repository

References

references/spec-template.md — six-area spec, assumption list, success-criteria reframe

---name: spec-driven-developmentdescription: Creates specs before coding. Use when starting a new project, feature, or significant change and no specification exists yet. Use when requirements are unclear, ambiguous, or only exist as a vague idea. Do not use when a spec already exists, or for small bugfixes that do not change intended behaviour.---# Spec-Driven Development## OverviewWrite a structured specification before writing any code. The spec is the shared source of truth between you and the human engineer — it defines what we're building, why, and how we'll know it's done. Code without a spec is guessing.## When to use- Starting a new project or feature- Requirements are ambiguous or incomplete- The change touches multiple files or modules- You're about to make an architectural decision- The task would take more than 30 minutes to implementDo not use for single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. If a spec already exists, do not write another — implement against it.## ProcessDo not advance a phase until the current one is validated:```SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT```1. **Specify.** Surface assumptions first. Cover objective, commands, project structure, code style, testing strategy, and boundaries (Always / Ask first / Never). Reframe vague requirements as testable success criteria. Spec template: `references/spec-template.md`.2. **Plan.** Components, order, risks, parallel vs sequential, checkpoints. Canonical slicing lives in `planning-and-task-breakdown`. Save `tasks/plan.md` and `tasks/todo.md`.3. **Tasks.** One focused session each, with acceptance criteria, verification, ≤ ~5 files, ordered by dependency.4. **Implement** with `incremental-implementation` and `test-driven-development`. Load the right spec sections via `context-engineering`.5. **Keep the spec alive.** Update it when decisions or scope change; commit it; link it from PRs.## Red flags- Starting to write code without any written requirements- Asking "should I just start building?" before clarifying what "done" means- Implementing features not mentioned in any spec or task list- Making architectural decisions without documenting them- Skipping the spec because "it's obvious what to build"## VerificationBefore proceeding to implementation, confirm:- [ ] The spec covers all six core areas- [ ] The human has reviewed and approved the spec- [ ] Success criteria are specific and testable- [ ] Boundaries (Always/Ask First/Never) are defined- [ ] The spec is saved to a file in the repository## References- `references/spec-template.md` — six-area spec, assumption list, success-criteria reframe

Frequently asked questions