Spec-Driven-Development

The problem this skill names is real and specific: you ask Claude Code to build a feature, Cursor contradicts it, Copilot invents a third interpretation — because none of the agents share a source of truth. The fix is procedural rather than clever: three files (requirements.md, design.md, tasks.md) written before any code, with requirements carrying shall-language REQ-xxx IDs and acceptance criteria, and tasks linking back to those IDs. Because the format is plain Markdown with a consistent schema, the spec stays reviewable by humans and readable by every agent — there's no proprietary runtime to adopt. The second half is the part teams actually feel: the skill generates the correct config file for each tool it supports, and each embeds the same Universal Instruction Block telling the agent to read the spec, cite requirement IDs, and follow a divergence protocol. That is the mechanism that stops Cursor and Copilot from quietly disagreeing. Two modes keep it usable at both ends of a project's life. Greenfield mode runs a four-question conversational interview and drops requirements.md, design.md, tasks.md, and CLAUDE.md into the project root. Retrofit mode works backwards from code you already have, and — importantly — it flags every inference with [TO VERIFY] and makes Phase 1 of tasks.md a spec-verification pass rather than new code, so the AI can't silently launder its guesses into your requirements. Setup matches the ambition: download the .skill file and install via Claude's Skills menu, run `claude plugin install FredAntB/spec-driven-development`, or clone and open in Claude Code, where CLAUDE.md is auto-read at session start. The honest weaknesses follow from what it is. It is a Claude skill, so it needs a Claude environment — Claude.ai, the Claude desktop app, or Claude Code — and its output quality tracks the answers you give in the interview; thin answers produce thin requirements. It is not a standalone service, has no dashboard, no API, and no server-side enforcement: the config files are instructions, not guardrails, so a determined agent can still ignore them. It's also early — the public repo shows 7 commits across branches including beta, phase2a, phase2b, and phase2c, and the Aider config (.aider.conf.yml) is explicitly labeled beta in the seed data — so expect the tool-support surface to move. Where it fits: teams of two or more running two or more AI coding agents over a shared repo, and anyone retrofitting a legacy codebase where AI tools keep misreading intent. Where it doesn't: solo devs on one agent who'd rather prompt ad hoc, teams that already have a spec discipline the AI can read, and anyone whose requirements can't be pasted into a Claude session. If you want a heavier, hosted requirements-management layer, look elsewhere; this is deliberately a thin, MIT-licensed skill you can read every line of.