How do I install the Spec Driven Development skill?

Run npx skillmds@latest add itsual/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. 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?

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

Spec Driven Development by itsual — Agent Skill

Name: Spec Driven Development
Author: itsual

Spec Driven Development

Create clear specifications and acceptance criteria before writing code. Use for any new feature, significant change, or when requirements are ambiguous. Trigger when the user says "spec", "requirements", "what should we build", or before starting non-trivial implementation.

itsual Updated Sep 21, 2026

File contents

Spec-Driven Development

Overview

Write a lightweight but precise specification before implementation. This prevents the most common agent failure mode: building the wrong thing confidently.

When to Use

New features or user stories
Significant refactors or architectural changes
Ambiguous requests
Before any non-trivial coding work

Core Process

1. Capture Intent

What problem are we solving? For whom? Why now?

2. Define Success

What does "done" look like from the user’s perspective?

3. Write the Spec

Keep it short. Focus on:

Problem statement
Goals (and non-goals)
User-facing behavior
Acceptance criteria (testable)
Edge cases & error handling
Constraints (performance, compatibility, security, etc.)
Open questions

4. Review & Agree

Surface the spec to the user for confirmation before coding.

Recommended Spec Template

# Spec: [Feature Name]

## Problem
...

## Goals
- ...

## Non-Goals
- ...

## User Stories / Behavior
- As a ... I want ... so that ...

## Acceptance Criteria
- [ ] ...
- [ ] ...

## Edge Cases
- ...

## Technical Notes / Constraints
- ...

## Open Questions
- ...

Principles

Prefer concrete, testable statements over vague ones
Explicitly call out non-goals to prevent scope creep
Keep the spec living — update it if requirements change
A good spec makes implementation and review much easier

Verification

Before writing code, confirm:

The user has seen and agreed with the spec (or key parts)
Acceptance criteria are specific enough to test against
Major assumptions are documented

---name: spec-driven-developmentdescription: Create clear specifications and acceptance criteria before writing code. Use for any new feature, significant change, or when requirements are ambiguous. Trigger when the user says "spec", "requirements", "what should we build", or before starting non-trivial implementation.---# Spec-Driven Development## OverviewWrite a lightweight but precise specification before implementation. This prevents the most common agent failure mode: building the wrong thing confidently.## When to Use- New features or user stories- Significant refactors or architectural changes- Ambiguous requests- Before any non-trivial coding work## Core Process### 1. Capture IntentWhat problem are we solving? For whom? Why now?### 2. Define SuccessWhat does "done" look like from the user’s perspective?### 3. Write the SpecKeep it short. Focus on:- **Problem statement**- **Goals** (and non-goals)- **User-facing behavior**- **Acceptance criteria** (testable)- **Edge cases & error handling**- **Constraints** (performance, compatibility, security, etc.)- **Open questions**### 4. Review & AgreeSurface the spec to the user for confirmation before coding.## Recommended Spec Template```markdown# Spec: [Feature Name]## Problem...## Goals- ...## Non-Goals- ...## User Stories / Behavior- As a ... I want ... so that ...## Acceptance Criteria- [ ] ...- [ ] ...## Edge Cases- ...## Technical Notes / Constraints- ...## Open Questions- ...```## Principles- Prefer concrete, testable statements over vague ones- Explicitly call out non-goals to prevent scope creep- Keep the spec living — update it if requirements change- A good spec makes implementation and review much easier## VerificationBefore writing code, confirm:- The user has seen and agreed with the spec (or key parts)- Acceptance criteria are specific enough to test against- Major assumptions are documented

Frequently asked questions