Spec-Driven Development workflow: specs, plans, gates, status and logbook tools. Bilingual EN/ES.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
We haven't yet run this listing's install command through our automated sandbox check. This isn't a red flag β we're steadily working through the catalog.
π‘ Paste the JSON block into your client's configuration file under mcpServers, then restart the application.
Learn Spec-Driven Development, then use it on real projects.
One rule: no code until you approve a written spec. A script checks that rule every time you run it, and prints exactly what it looked at.
πΊπΈ English Β· πͺπΈ EspaΓ±ol
Non-technical start Β· Quickstart Β· AI agent start Β· Commands Β· Community
Spec-Driven Development (SDD) means writing and approving a clear specification before any code exists. What you decided ends up in a file, instead of buried in a chat you will close and never find again. By 2026 it is how most people build software with AI agents.
This repo does double duty.
It is a school: a bilingual (EN/ES) path that starts from zero, with guides, an interactive course and a tutor you can talk to. You do not need to know how to program to get through it.
It is also a toolkit for real work: scripts that check the rule, instruction files your AI assistant reads, a connector so your AI tool can run the workflow itself (MCP, the Model Context Protocol), and a single spec/ folder you add to a project that already has code β without moving any of it.
The step-by-step commands come from GitHub Spec Kit. This repo adds the guides, the checks and the templates on top of them.
The flow in action β create a spec, validate, pass the gate (regenerated on every release):
What changes in practice: decisions stop living in chat history and move into specs/. The gate stays closed until spec.md and plan.md exist, agree, and you record your consent β a script checks that, not somebody's memory. A new teammate or a new agent lands in a folder layout they already recognize. And bitacora/ keeps the session log, so six months later you can still find out why something was done the way it was.
Want the industry map? Read SDD in 2026: state of the art and how this template compares.
Then pick your learning level. Every guide on the docs site carries its level badge:
[!TIP] If you would rather learn by doing, take the interactive course (GitHub Skills format): 4 steps, ~35 min, auto-graded by Actions. Your exam is the real SDD gate.
Copy/paste this prompt into your AI assistant (Claude, Cursor, Copilot, Gemini...):
If you use Claude Code, this repo ships slash commands out of the box. Start with /sdd:help:
| Command | What it does |
|---|---|
/sdd:help | Tells you what stage you are in and the single next step |
/sdd:new | Guided start: idea β first spec ready for approval |
/sdd:spec | Create or refine a spec bundle with EARS criteria |
/sdd:gate | Runs the gate β approval, plan consistency, consent β and records yours |
/sdd:decision | One decision, written down in bitacora/decisiones/: what, why, what was rejected, when to revisit |
/sdd:close | Validates and closes the session with the output contract |
/sdd:tutor | A conversational SDD course by levels, graded by the real validation scripts |
Install in any project as a plugin (no cloning):
.github/prompts/../scripts/generate-llms-txt.sh).[!IMPORTANT] No code before an approved
spec.mdand a consistentplan.md. A script enforces this, and implementation starts only once your consent is on record.
(In sidecar projects the same scripts live under ./spec/scripts/.)
Enforce it in CI too. This repo doubles as a GitHub Action, listed on the GitHub Marketplace:
Reference files: sdd.policy.yaml Β· INSTRUCTIONS.md Β· AGENT_OPERATING_SYSTEM.md
Every feature gets a numbered spec bundle, and every session leaves a trace in bitacora/ (the logbook):
spec.md β what and why (approved by you)plan.md β how (consistent with the spec)tasks.md β concrete stepshistory.md β how it evolvedFull walkthrough example: examples/002-mcp-end-to-end
Fastest start (no clone needed):
It asks a few questions and scaffolds the recommended spec/ sidecar, or a full workspace, from the latest template.
Three ways to use the template, from lightest to heaviest:
| Mode | When | Command |
|---|---|---|
Compact spec/ sidecar β | Real or existing project: SDD artifacts in ./spec/, code stays in your project root | ./scripts/install-spec-sidecar.sh /path/to/project --profile=recommended |
Internal workspace www/ | The runnable project should live inside this template repo | ./scripts/create-www-project.sh my-project codex |
| Full standalone copy | You explicitly want the whole framework as your workspace | ./scripts/init-project.sh /path/to/project --profile=full |
[!TIP] The professional default is the compact
spec/sidecar and nothing else. Never copy the full framework into a real codebase unless you actually want standalone mode.
| Action | Command |
|---|---|
| New spec | ./spec/scripts/new-spec.sh "my-feature" "Owner" |
| Validate structure | ./spec/scripts/validate-sdd.sh . --strict |
| Policy check | ./spec/scripts/check-sdd-policy.sh . |
| SDD gate | ./spec/scripts/check-sdd-gate.sh . |
| Status dashboard | ./spec/scripts/generate-status.sh |
Folder anatomy and layout details: project organization map
No reviews yet β be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/sdd-mcp)<a href="https://allmcps.com/mcp/sdd-mcp"><img src="https://allmcps.com/api/badge/sdd-mcp?style=directory" alt="Sdd MCP on AllMCPs" /></a>