What does this skill do, and when should you use it?
This skill requires a structured specification before coding a new project, feature, or significant change. It surfaces assumptions, clarifies requirements, and defines a shared source of truth between the human engineer and the agent. After human validation, it produces an implementation plan and dependency-ordered task list before implementation begins. It is explicitly unnecessary for one-line fixes, typo corrections, and clear, self-contained changes.
Determines whether specification-first work is appropriate; asks clarifying questions and exposes assumptions; creates a specification covering the objective, technology stack, commands, project structure, code style, testing strategy, boundaries, success criteria, and open questions; reframes vague requirements as concrete, testable success criteria; after validation, creates a technical plan and task list, saving them to tasks/plan.md and tasks/todo.md; verifies before implementation that the specification has human approval, testable success criteria, defined boundaries, and a repository file.
- An engineer starting a new project needs explicit goals, stack, structure, commands, and acceptance criteria before implementation.
- A developer has an ambiguous feature request and needs assumptions and unresolved questions surfaced for human confirmation.
- A change spans multiple files or modules and requires dependency ordering, risk notes, and verification checkpoints.
- A team is about to make an architectural decision and wants the decision context, boundaries, and success criteria documented first.
How do you install this skill?
- The referenced planning-and-task-breakdown, incremental-implementation, test-driven-development, and context-engineering skills were not supplied, so execution consistency cannot be confirmed.
- The skill requires human approval at each phase but does not define clear recovery paths for timeout, rejection, inability to write tasks/ files, or command failure.
- It does not specify how to handle sensitive information, credentials, or proprietary requirements in specifications and commits.
- Local filesystem
The skill is located at skills/spec-driven-development/SKILL.md in the addyosmani/agent-skills repository. Install the full collection with: npx skills add addyosmani/agent-skills. Install only this skill with: npx skills add addyosmani/agent-skills --skill spec-driven-development. The README does not document single-skill installation steps for other clients.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/addyosmani/agent-skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/spec-driven-development" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- I’m starting a new feature; write the specification first and do not code yet.
Trigger spec-driven-development in an Agent Skills-compatible coding agent, or use a request such as “I’m starting a new feature; write the specification first and do not code yet.” Complete the specification and obtain human review before generating tasks/plan.md and tasks/todo.md, then proceed to implementation.
What are this skill's strengths and limitations?
- Covers six concrete specification areas: objective, commands, structure, code style, testing strategy, and boundaries.
- Surfaces assumptions instead of silently filling gaps in requirements.
- Uses four gated phases—Specify, Plan, Tasks, and Implement—with human review at each phase.
- Treats the specification as a living document that should be updated and versioned with the code.
- The full workflow can add overhead for small, unambiguous changes, which the skill itself excludes.
- Implementation depends on sibling skills such as incremental implementation and test-driven development; this skill does not define the complete coding or testing workflow itself.
- The supplied source provides no independent automated test suite or cross-client validation evidence for this skill.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Spec-Driven Development this page | 55 · Use with care | ★ 107k | 13d ago | MIT |
| Planning & Task Breakdown | 54 · Use with care | ★ 107k | 13d ago | MIT |
| DeepChat Spec-Driven Development Skill | 58 · Recommended | ★ 6.4k | 14d ago | Apache-2.0 |
| Grill-Me Design Interview | 57 · Use with care | ★ 28k | 12d ago | MIT |
| Loki Mode Autonomous SDLC Skill | 53 · Use with care | ★ 1.1k | 18d ago | NOASSERTION |
The README names Superpowers and Matt Pocock's skills as alternatives, but the supplied material does not provide substantive comparison findings.
How did FollowSkills review this skill?
The skill requires surfacing assumptions, human review at each phase, and Always/Ask first/Never boundaries, providing partial least-privilege and confirmation controls. It does not address sensitive-data handling, external side effects, dependency security, data-flow disclosure, or concrete recovery procedures; publisher identity is also unverified, so points are deducted.
The phases, templates, gates, and pre-implementation checks are internally coherent, and repository CI validates skill structure and trigger evaluations. The supplied files contain no executed reproduction of this skill's key paths, while abnormal-input handling, missing-human-approval behavior, and diagnostics for unavailable referenced skills are thin; the static cap keeps this at 8.
Target scenarios and non-fit cases are clearly stated, including new projects, significant changes, and ambiguous requirements. Inputs and outputs, semantic trigger boundaries, Chinese-language guidance, and mainland-China environment fit are not specified; the workflow also depends on other skills and command conventions, so points are deducted.
The document has clear information architecture with overview, applicability, gated phases, templates, anti-rationalization guidance, and verification criteria, and it follows the repository's progressive-disclosure model. It lacks skill-specific versioning, changelog, maintenance ownership, and update path; installation and dependency notes are mostly delegated to the repository README.
The skill can directly produce a specification, plan, task list, and testable acceptance criteria, with clear value for clarifying requirements and reducing rework. Results still depend on human approvals, other skills, and project-specific commands, and the supplied material does not directly prove file creation or implementation outcomes; static calibration limits this to 6.
The skill includes a six-part specification template, success criteria, and a verification checklist, while the repository provides CI, structural validation, and trigger-evaluation workflows. The supplied test fixture is unrelated to this skill's key paths, and there is no third-party execution evidence or independent corroboration, so verifiability remains limited.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →