---
name: spec-driven-development-spec-kit
description: "GitHub Spec Kit spec-driven development — /specify, /plan, /tasks, /implement, constitution.md, EARS specs. Runs the full GitHub Spec Kit loop: scaffold with `specify init`, set engineering principles in constitution.md, then /specify to write spec.md, /clarify to resolve ambiguities, /plan to produce plan.md and research/data-model/contracts, /tasks to generate tasks.md, /analyze for cross-artifact consistency, and /implement. Covers EARS-style acceptance criteria, the .specify/ directory layout, and driving agents predictably instead of vibe-coding."
license: MIT
---

# Spec Kit SDD

This skill drives GitHub's Spec Kit through its full spec-driven development loop, so you write an explicit specification, plan, and task list before any implementation code exists. It's aimed at developers who want an AI agent to build against a reviewed, version-controlled intent — not a vibe-coded prompt — and who care about traceability from requirement to commit.

## When to use it

- Starting a new feature where the requirements still have open questions you want surfaced and resolved up front.
- Working on a team that reviews specs and plans in PRs before code lands.
- Re-architecting an existing module and you want a checked-in `plan.md`, data model, and contracts to align on first.
- You keep getting half-right AI output because the agent guessed at acceptance criteria — EARS-style specs force those into the open.

## How it works

The skill scaffolds a project with `specify init` (CLI installable via `uv tool install specify-cli` from the spec-kit repo), then runs the slash-command workflow inside your agent:

- `/constitution` — write `memory/constitution.md` with non-negotiable engineering principles (testing, library-first, observability) that every later step must respect.
- `/specify` — produce `spec.md`: user stories and acceptance criteria, written in EARS phrasing ("WHEN <trigger>, the system SHALL <response>").
- `/clarify` — interrogate the spec for ambiguities and underspecified behavior, recording answers back into `spec.md`.
- `/plan` — generate `plan.md` plus supporting artifacts: `research.md`, `data-model.md`, and a `contracts/` directory.
- `/tasks` — derive an ordered, dependency-aware `tasks.md`.
- `/analyze` — cross-check spec, plan, and tasks for inconsistencies before you commit to building.
- `/implement` — execute the task list against the plan.

Artifacts live under a per-feature directory (e.g. `specs/001-feature-name/`) so each feature carries its own spec, plan, and tasks in git.

## Usage example

```bash
curl -fsSL --create-dirs -o ~/.claude/skills/spec-driven-development-spec-kit/SKILL.md https://claudeskil.com/skills/spec-driven-development-spec-kit/SKILL.md

# scaffold (Spec Kit CLI)
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
specify init my-app
cd my-app

# then, inside your agent:
/constitution Principles: test-first, no feature without a contract
/specify Build a URL shortener with custom slugs and click analytics
/clarify
/plan Use Postgres, FastAPI, expose REST contracts under /api
/tasks
/analyze
/implement
```

## Tips & gotchas

- Run `/clarify` *before* `/plan` — planning over an ambiguous spec bakes the wrong assumptions into `data-model.md` and contracts.
- The constitution is enforced downstream; vague principles produce vague gates. Make them checkable ("every endpoint has a contract test").
- `/analyze` is read-only triage — it reports drift but won't fix it. Re-run `/specify` or `/plan` to reconcile.
- Spec Kit is agent-agnostic; the same `spec.md`/`plan.md` work across Claude, Copilot, Cursor, and others.

## FAQ

**Do I have to use every command?** No. The common minimum is `/specify` → `/plan` → `/tasks` → `/implement`. Add `/constitution`, `/clarify`, and `/analyze` as your need for rigor grows.

**Does it overwrite my existing repo?** `specify init` scaffolds the `.specify`/templates structure; use `specify init --here` to add it into the current directory rather than creating a new one.

**Where do the specs live?** Committed under `specs/<feature>/`, so they review and diff like code.