Skip to content
/

FredAntB/Spec-Driven-Development

spec-driven-fredantb · FredAntB/Spec-Driven-Development · ★ 57 · last commit 2026-05-23

Conversational skill that interviews the user once, generates requirements/design/tasks, then creates identical Universal Instruction Blocks for every AI tool so they can't contradict each other.

Best whenThe root cause of AI drift is missing shared source of truth — solve it by generating identical instruction blocks for all tools in one session, not by restr…
Skip ifImplementing requirements not in requirements.md, Altering data model without updating design.md first
vs seeds
openspec(Archetype 2 — cross-tool commands+skills) but delivers via a single conversational skill instead of an npm CLI. The Uni…
Primitive shape 1 total
Skills 1
00

Summary

FredAntB/Spec-Driven-Development — Summary

A Claude skill that generates the three-document spec set (requirements.md, design.md, tasks.md) for any project, then creates matching AI config files (CLAUDE.md, .cursorrules, .windsurfrules, Copilot instructions, .aider.conf.yml) so that all AI tools read the same spec. The problem it solves: Claude, Cursor, and Copilot contradict each other because they each fill spec gaps with different assumptions.

The SKILL.md contains a conversational interview protocol (four required answers, one question at a time) with a hard generation gate: no files may be created until all four interview answers are in hand. The CLAUDE.md it generates enforces hard constraints at session start (never implement beyond requirements.md, never alter data model without updating design.md first).

Both greenfield (new project) and brownfield (existing codebase) workflows are supported. The brownfield path reverse-engineers existing code into spec files marked v0-retrofit with [TO VERIFY] annotations on all inferred fields.

57 stars, active development. Closest seed match is openspec (Archetype 2 — cross-tool spec generation), but FredAntB differs by shipping a conversational interview skill rather than a CLI, and by generating tool-specific config files rather than maintaining a single spec.

01

Overview

FredAntB/Spec-Driven-Development — Overview

Origin

Created by FredAntB. Repository description: "A Claude skill that keeps your AI coding tools from contradicting each other. Generates requirements.md, design.md, and tasks.md before any code is written — then creates matching config files for Claude Code, Cursor, Copilot, Windsurf, and Aider." 57 stars, Python language, active as of 2026-05-23.

Philosophy

The root cause of drift between AI tools is a missing shared source of truth:

"You open Claude Code and ask it to build a feature. An hour later it's done something technically impressive that isn't quite what you wanted. You ask Cursor to fix it. It contradicts what Claude Code did. You ask Copilot to clean up. It invents a third interpretation. The root cause is always the same: your AI agents have no shared source of truth. They fill every gap with their own assumptions."

The fix: create three spec files before any code is written. Every AI tool reads from these files and gets the same mandate.

From the "Universal Instruction Block" that goes into every AI config file:

═══════════════════════════════════════════════════════════
SPEC DRIVEN DEVELOPMENT — PROJECT CONSTITUTION
Project: Your Project Name
Version: 1.0
═══════════════════════════════════════════════════════════

This project uses Spec Driven Development. All work is governed
by three source-of-truth files:
  requirements.md  — What the system must do
  design.md        — How the system is structured
  tasks.md         — The ordered implementation plan

Hard constraints generated in CLAUDE.md

Every generated CLAUDE.md contains:

  • "Never implement requirements not in requirements.md"
  • "Never alter the data model without updating design.md first"
  • "Never create files not listed or implied in design.md"
  • "Never mark a task [x] without verifying its acceptance criterion"
  • "Never guess when a requirement is ambiguous — ask instead"

Traceability through task IDs

tasks.md links every task to its requirement:

- [ ] **TASK-003** [REQ-001]: Implement POST /entries with validation
  - _Output_: Route handler + duration schema validation
  - _Verify_: POST /entries returns 201 with all required fields
02

Architecture

FredAntB/Spec-Driven-Development — Architecture

Distribution

  • Type: standalone-repo (Claude skill + methodology)
  • Install: Plugin install or git clone
  • Install complexity: multi-step

Install commands

# Claude.ai / Claude desktop (Chat tab)
# Download spec-driven-development-v1.0.skill → Claude settings → Skills → Install

# Or via CLI:
claude plugin install FredAntB/spec-driven-development

# For Claude Code (Code tab):
git clone https://github.com/FredAntB/Spec-Driven-Development
# Open folder in Code tab; CLAUDE.md is auto-read at session start

Directory tree

Spec-Driven-Development/
├── CLAUDE.md               ← Auto-read at session start (bootstraps skill)
├── SKILL.md                ← The skill prompt (interview + generation)
├── LICENSE
├── references/
│   ├── sdd-curriculum.md   ← Teaching curriculum (newbie to hero)
│   ├── capabilities-and-cross-ai.md  ← Claude Code capabilities + cross-AI strategy
│   └── templates.md        ← All spec file + AI config templates
├── beta/                   ← Beta features
├── phase2a/                ← Assertion tests (67/67 passing)
│   └── assertions.md
├── phase2b/                ← Behavioral tests (15/15 passing)
│   └── eval_session.md
├── phase2c/                ← Generation quality tests (53/53 passing)
│   └── eval_flows.md
└── README.md

Generated output (what the skill creates in the user's project)

user-project/
├── requirements.md                      ← REQ-xxx with acceptance criteria
├── design.md                            ← Data model, API, file structure
├── tasks.md                             ← TASK-xxx [REQ-xxx] ordered steps
├── CLAUDE.md                            ← Claude Code (with hard constraints)
├── .cursorrules                         ← Cursor
├── .windsurfrules                       ← Windsurf
├── .github/copilot-instructions.md      ← GitHub Copilot
└── .aider.conf.yml                      ← Aider

Required runtime

None — the skill runs within Claude's context window.

Target AI tools

Multi-tool. Every generated config file contains the same Universal Instruction Block:

  • Claude Code (CLAUDE.md)
  • Cursor (.cursorrules)
  • Windsurf (.windsurfrules)
  • GitHub Copilot (.github/copilot-instructions.md)
  • Aider (.aider.conf.yml)
03

Components

FredAntB/Spec-Driven-Development — Components

Skills (1)

Skill File Purpose
spec-driven-development SKILL.md Full SDD workflow: interview user, generate requirements/design/tasks, create cross-AI config files

The skill is the entire framework. It contains:

  • Greenfield workflow (new project)
  • Brownfield workflow (retrofit existing codebase)
  • Interview protocol (4 required questions, one at a time)
  • Generation gate (hard: no files until all 4 answers in hand)
  • Requirements generation rules (REQ-xxx IDs, "shall" language, concrete acceptance criteria)
  • Design generation rules (data model, API endpoints, file structure)
  • Tasks generation rules (ordered, TASK-xxx [REQ-xxx] inline references, verification steps)
  • AI config generation rules (Universal Instruction Block identical across all tools)

Commands

None.

Subagents

None.

Hooks

None.

MCP Servers

None.

Scripts

None.

Templates

The references/templates.md file contains all templates used by the skill:

  • requirements.md template
  • design.md template
  • tasks.md template
  • CLAUDE.md template
  • .cursorrules template
  • .windsurfrules template
  • .github/copilot-instructions.md template
  • .aider.conf.yml template

Reference files

File Purpose
references/sdd-curriculum.md Teaching curriculum from newbie to expert
references/capabilities-and-cross-ai.md Claude Code capabilities + cross-AI strategy
references/templates.md All spec file and AI config templates

CONTEXT.md (generated artifact for session continuity)

The generated CLAUDE.md instructs the agent to maintain a CONTEXT.md file:

  • Session log (date, one-line summary, files changed)
  • Resume block (next active task)
  • Divergence record (deviations from design.md)
  • Open questions

This is created by Claude during use, not shipped by the repo.

05

Prompts

FredAntB/Spec-Driven-Development — Prompts

Excerpt 1 — SKILL.md interview protocol (verbatim)

## When to Read Reference Files

| Situation | Read |
|---|---|
| User is new to SDD and needs explanation | `sdd-curriculum.md` Levels 1–3 |
| User asks about Claude Code + SDD specifics | `capabilities-and-cross-ai.md` Part 1 |
| User wants cross-AI config files | `capabilities-and-cross-ai.md` Part 2–3 |
| You need template content to generate files | `templates.md` |

---

## Workflow: First Run (New Project)

### Step 1: Interview the User

**Conversational rule (non-negotiable):** Ask exactly ONE question, wait for the answer, then ask the next. Never present questions as a numbered list or bullet list — that feels like a form, not a conversation. A newbie who sees three bullets may answer only the first or feel overwhelmed.

Prompting technique: Anti-list-dump instruction. The skill explicitly forbids presenting multiple questions as a list and explains the UX reason ("feels like a form"). This shapes the conversation to feel natural rather than clinical.

Excerpt 2 — Generation gate (SKILL.md verbatim)

### Generation Gate (enforced between Step 1 and Step 2)

**HARD RULE: No file of any kind may be generated until all four interview answers are in hand.**

This gate applies to every output path — `requirements.md`, `design.md`, `tasks.md`, `.cursorrules`, `CLAUDE.md`, and all other config files. There are no exceptions, including when:
- The user says "create requirements for X" (X is a product category, not a full description)
- The user says "make a cursorrules file" (a concrete deliverable name is not permission to skip the interview)
- The user says "set up Cursor and Claude Code" (naming tools is not the same as providing project context)
- The user gives a partial stack answer like "Node.js" (stack ≠ deployment — both are required separately)

**Gate check before generating any file:**
□ Do I know what the project does and who uses it?    → if not, ask first
□ Do I know the tech stack (language/framework/db)?   → if not, ask first
□ Do I know the deployment target?                    → if not, ask first
□ Do I know which AI tools the user uses?             → if not, ask first
Only when all four are ✓ → proceed to Step 2

Prompting technique: Explicit bypass enumeration. The gate instruction names five common bypass attempts (naming a product category, requesting a specific file, naming tools) and explicitly rejects each one. This pre-handles the most frequent gate violations.

Excerpt 3 — CLAUDE.md hard constraints (verbatim)

## Hard constraints

- Never implement requirements not in requirements.md
- Never alter the data model without updating design.md first
- Never create files not listed or implied in design.md
- Never mark a task `[x]` without verifying its acceptance criterion
- Never guess when a requirement is ambiguous — ask instead

Prompting technique: Absolute-prohibition format. Each constraint uses "Never" (not "Try to avoid" or "Should not") creating categorical prohibitions rather than soft preferences.

09

Uniqueness

FredAntB/Spec-Driven-Development — Uniqueness

differs_from_seeds

Closest to openspec (Archetype 2 — cross-tool commands+skills) but with a fundamentally different delivery mechanism: where openspec ships an npm CLI that installs commands, FredAntB ships a single conversational skill that interviews the user and generates all artifacts in one session. The cross-tool config generation (CLAUDE.md + .cursorrules + .windsurfrules + Copilot instructions + Aider config — all identical Universal Instruction Block) is the same problem openspec solves but via a different mechanism. The CONTEXT.md session-log pattern (update at session end, read at session start, divergence recording) is unique among seeds — no seed implements this level of session-continuity bookkeeping in the generated CLAUDE.md. The brownfield retrofit path with v0-retrofit versioning and [TO VERIFY] annotations is also distinctive: most frameworks assume greenfield or ignore the reverse-engineering use case.

Positioning

The best-fit tool for developers who want AI tools to stop contradicting each other with a single conversational interaction. The interview-driven generation means users don't need to learn a CLI or understand the methodology — they just answer four questions and get working spec files.

The 57 stars and active CI badges (67/15/53 tests all green) suggest a polished, well-tested single-author framework.

Observable failure modes

  1. Interview dependency: If the user gives evasive or partial answers (e.g., "Node.js" for tech stack, skipping deployment), the gate enforces stopping but may frustrate users who want to start immediately.
  2. Conversation-only: The skill is not accessible from the command line — it requires an active Claude conversation. Teams that prefer CLI-driven workflows cannot use it without adaptation.
  3. No enforcement after generation: Once the spec files are created, compliance with requirements.md is enforced only by the hard constraints in CLAUDE.md (which the AI self-enforces). There are no hooks, validators, or CI checks.
  4. No task dependency graph: tasks.md uses inline REQ references but is a flat checklist. Complex dependency chains require manual ordering.
  5. Single skill: There is no /spec:review, /spec:check, or /spec:stats equivalent — the framework ships one skill for generation only.
04

Workflow

FredAntB/Spec-Driven-Development — Workflow

Greenfield workflow (new project)

Phase 1: Interview (one question at a time)

Hard gate: No file is generated until ALL FOUR answers are in hand.

Required questions (asked one at a time, conversationally):

  1. What the project does and who uses it 2a. Tech stack (language, framework, database) 2b. Deployment target (Railway, Fly.io, AWS, Vercel, etc.)
  2. Which AI coding tools they use (Claude Code, Cursor, Windsurf, Copilot, Aider)

Optional follow-ups (only if ambiguous):

  • Performance/security/accessibility constraints?
  • Out of scope for first version?

Phase 2: Generate requirements.md

Rules:

  • Every functional requirement uses "shall" language (REQ-xxx: Actor shall verb object)
  • Every requirement has a concrete acceptance criterion
  • NFRs have measurable metrics (not "fast" — use "< 200ms at p95")
  • Out of scope section is non-empty
  • REQ IDs are sequential from REQ-001

Phase 3: Generate design.md

Rules:

  • Every REQ-xxx must map to at least one data model field, endpoint, or component
  • Data model fields have explicit types and constraints
  • API endpoints reference the REQ they satisfy
  • File structure section shows top 2 levels
  • Open Questions section for undecided items

Phase 4: Generate tasks.md

Rules:

  • Tasks ordered: infrastructure → data layer → business logic → API → tests → validation
  • Every task references at least one REQ/NFR inline on the checkbox line
  • Every task has an explicit verification step
  • Tasks are atomic (≤ ~200 lines of new code)
  • TASK-xxx [REQ-xxx] format on every checkbox line

Phase 5: Generate AI config files

One Universal Instruction Block, identical content across all tools. Tool-specific additions ≤ 5 lines.

Brownfield workflow (retrofit existing codebase)

Different interview (5 questions):

  1. What does the system do today?
  2. Tech stack + deployment
  3. Which AI tools?
  4. Can you share files to read? (offers to read actual structure)
  5. What's the next planned feature/phase?

Retrofit generation:

  • requirements.md: marked v0-retrofit, inferred requirements confirmed back to user
  • design.md: schema fields marked [unknown] if not shared, sections marked [TO VERIFY]
  • tasks.md: Phase 1 = spec verification, not new code

Divergence protocol (from generated CLAUDE.md)

If implementation must deviate from design.md:

  1. Stop
  2. Describe conflict
  3. Wait for explicit user approval
  4. Update design.md FIRST
  5. Record divergence in CONTEXT.md

Approval gates

Gate Type
Interview gate: all 4 answers required yes-no
Implicit per-phase review (read before continuing) file-review
Divergence from design.md → explicit approval yes-no
06

Memory Context

FredAntB/Spec-Driven-Development — Memory & Context

State storage

File-based. Three spec files + CONTEXT.md for session continuity:

user-project/
├── requirements.md     ← Source of truth for WHAT
├── design.md           ← Source of truth for HOW
├── tasks.md            ← Source of truth for task ordering + status
└── CONTEXT.md          ← Session log + resume block + divergences

CONTEXT.md structure (from generated CLAUDE.md instructions)

## Session log
| Date | Session | Summary | Files changed |
|---|---|---|---|
| 2026-05-01 | 1 | Initial setup | requirements.md, design.md, tasks.md |

## Resume block
**Next task**: TASK-004 [REQ-002]: Implement user login endpoint
**Status**: In progress

## Divergences from design.md
None yet.

## Open questions
- [ ] Should rate limiting be per-IP or per-user?

Persistence

  • Project level: All three spec files committed to repository
  • Session level: CONTEXT.md updated at end of each session

Cross-session handoff

Handled by CONTEXT.md resume block. At session start, Claude reads:

  1. CONTEXT.md (resume block → pick up next task)
  2. requirements.md
  3. design.md
  4. tasks.md (find next incomplete [ ])

Compaction handling

Not explicitly addressed by hooks (no hooks shipped). The CLAUDE.md session startup instructions serve as a manual compaction recovery mechanism.

Memory type

File-based. Plain Markdown.

State files

File Content Owner
requirements.md REQ-xxx with acceptance criteria Skill-generated
design.md Data model, API, file structure Skill-generated
tasks.md TASK-xxx [REQ-xxx] ordered steps with checkboxes Skill-generated
CONTEXT.md Session log + resume block + divergences Agent-maintained
CLAUDE.md Hard constraints + session startup rules Skill-generated
.cursorrules / .windsurfrules / etc. Universal Instruction Block Skill-generated
07

Orchestration

FredAntB/Spec-Driven-Development — Orchestration

Multi-agent support

None. Single-agent workflow.

Orchestration pattern

Sequential. Interview → requirements → design → tasks → AI config generation. Each step depends on the prior.

Isolation mechanism

None. In-place file creation in the user's project directory.

Execution mode

Interactive-loop. The skill is conversational — it asks questions, waits for answers, then generates files.

Multi-model routing

None.

Prompt chaining

Yes, implicit. The skill reads its own generated outputs to ensure consistency:

  • requirements.md is read before design.md is generated (every REQ maps to design elements)
  • design.md is read before tasks.md is generated (tasks are ordered by dependency chain)

Consensus mechanism

None.

Auto-validators

None automated. The CLAUDE.md hard constraints serve as the runtime enforcement layer:

  • "Never implement requirements not in requirements.md"
  • "Never mark a task [x] without verifying its acceptance criterion"

Validation is manual (human reads and verifies).

Session state management

The CONTEXT.md file provides a lightweight audit log and resume mechanism. At session end, Claude updates:

  • Session log row
  • Resume block (next task)
  • Any divergences from design.md

Git automation

None. The CLAUDE.md recommends commits but does not automate them.

Cross-tool consistency

The Universal Instruction Block (identical content in all AI config files) is the cross-tool consistency mechanism: all agents are governed by the same mandate, cite the same spec files, and follow the same divergence protocol.

08

Ui Cli Surface

FredAntB/Spec-Driven-Development — UI / CLI Surface

Dedicated CLI binary

None.

Local web dashboard

None.

IDE integration

Claude Code (primary) via the skill. The skill is accessible from:

  • Claude.ai / Claude desktop: install from .skill file via Settings → Skills
  • Claude Code CLI: claude plugin install FredAntB/spec-driven-development
  • Claude Code (Code tab): open cloned folder — CLAUDE.md is auto-read

The skill can be triggered by natural language:

  • "I want to start a new project"
  • "my AI keeps going off script, help"
  • "I already have a codebase, no specs yet"
  • "set up cursor and claude code for my team project"

Cross-tool output

The skill generates config files for 5 AI tools simultaneously:

  • Claude Code (CLAUDE.md)
  • Cursor (.cursorrules)
  • Windsurf (.windsurfrules)
  • GitHub Copilot (.github/copilot-instructions.md)
  • Aider (.aider.conf.yml)

Test coverage

The repo ships three test batteries:

  • phase2a/assertions.md — 67 static assertions (all passing)
  • phase2b/eval_session.md — 15 behavioral tests (all passing)
  • phase2c/eval_flows.md — 53 generation quality tests (all passing)

These are evaluation frameworks for the skill's output quality, not unit tests.

Observability

None. No audit log, no history command.

Related frameworks

same archetype · same primary tool · same memory type

claude-mem (thedotmack) ★ 78k

Background worker service captures every tool call as an observation, AI-compresses sessions, and auto-injects relevant past…

pi (badlogic/earendil) ★ 55k

A minimal, hackable, multi-provider terminal coding agent that adapts to your workflows via npm-installable TypeScript Extensions…

Agent Skills (Addy Osmani) ★ 46k

Encodes senior-engineer software development lifecycle as 23 auto-routed skills and 7 slash commands for any AI coding agent.

wshobson/agents Plugin Marketplace ★ 36k

Single Markdown source for 83 domain-specialized plugins that auto-generates idiomatic artifacts for five AI coding harnesses.

TabbyML/Tabby ★ 34k

Self-hosted AI coding assistant server (alternative to GitHub Copilot) with admin dashboard, RAG-based completions, and multi-IDE…

Compound Engineering ★ 17k

Make each unit of engineering work compound into easier future work via brainstorm→plan→execute→review→learn cycles.