Agent skill

Spec Driven Development

MITAuto-check passedDevelopment

Install Spec Driven Development

skills CLI

$ npx skills add magnus919/agent-skills --skill spec-driven-development -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI

$ gh skill install magnus919/agent-skills spec-driven-development --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy

$ git clone --depth 1 https://github.com/magnus919/agent-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/spec-driven-development .claude/skills/spec-driven-development && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Paste into Claude Code

Install the "spec-driven-development" agent skill from https://github.com/magnus919/agent-skills/tree/main/spec-driven-development into .claude/skills/spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "spec-driven-development", then confirm the skill loads.

Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

$skill-installer

$skill-installer install https://github.com/magnus919/agent-skills/tree/main/spec-driven-development

Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.

skills CLI

$ npx skills add magnus919/agent-skills --skill spec-driven-development -a codex

Project install goes to .agents/skills/; add -g for ~/.codex/skills/.

GitHub CLI

$ gh skill install magnus919/agent-skills spec-driven-development --agent codex

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/magnus919/agent-skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/spec-driven-development .agents/skills/spec-driven-development && rm -rf skills-src

Use ~/.agents/skills/ instead of .agents/skills for a personal install.

Codex skills documentation · loads skills from .agents/skills/

Paste into Codex

Install the "spec-driven-development" agent skill from https://github.com/magnus919/agent-skills/tree/main/spec-driven-development into .agents/skills/spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "spec-driven-development", then confirm the skill loads.

Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

skills CLI

$ npx skills add magnus919/agent-skills --skill spec-driven-development -a cursor

Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.

GitHub CLI

$ gh skill install magnus919/agent-skills spec-driven-development --agent cursor

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/magnus919/agent-skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/spec-driven-development .cursor/skills/spec-driven-development && rm -rf skills-src

Use ~/.cursor/skills/ instead of .cursor/skills for a personal install.

Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/

Paste into Cursor

Install the "spec-driven-development" agent skill from https://github.com/magnus919/agent-skills/tree/main/spec-driven-development into .cursor/skills/spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "spec-driven-development", then confirm the skill loads.

Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

gemini skills install

$ gemini skills install https://github.com/magnus919/agent-skills.git --path spec-driven-development

--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.

skills CLI

$ npx skills add magnus919/agent-skills --skill spec-driven-development -a gemini-cli

Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.

GitHub CLI

$ gh skill install magnus919/agent-skills spec-driven-development --agent gemini-cli

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/magnus919/agent-skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/spec-driven-development .gemini/skills/spec-driven-development && rm -rf skills-src

Use ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.

Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/

Paste into Gemini CLI

Install the "spec-driven-development" agent skill from https://github.com/magnus919/agent-skills/tree/main/spec-driven-development into .gemini/skills/spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "spec-driven-development", then confirm the skill loads.

Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

GitHub CLI

$ gh skill install magnus919/agent-skills spec-driven-development

Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).

skills CLI

$ npx skills add magnus919/agent-skills --skill spec-driven-development -a github-copilot

Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.

Manual copy

$ git clone --depth 1 https://github.com/magnus919/agent-skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/spec-driven-development .github/skills/spec-driven-development && rm -rf skills-src

Use ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.

GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/

Paste into GitHub Copilot

Install the "spec-driven-development" agent skill from https://github.com/magnus919/agent-skills/tree/main/spec-driven-development into .github/skills/spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "spec-driven-development", then confirm the skill loads.

GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

skills CLI

$ npx skills add magnus919/agent-skills --skill spec-driven-development -a opencode

OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.

GitHub CLI

$ gh skill install magnus919/agent-skills spec-driven-development --agent opencode

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/magnus919/agent-skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/spec-driven-development .opencode/skills/spec-driven-development && rm -rf skills-src

Use ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.

OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/

Paste into OpenCode

Install the "spec-driven-development" agent skill from https://github.com/magnus919/agent-skills/tree/main/spec-driven-development into .opencode/skills/spec-driven-development/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "spec-driven-development", then confirm the skill loads.

OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

Facts

Skill name: spec-driven-development
GitHub stars: 113
Token cost: ~3.8k tokens
SKILL.md length: 1,650 words
Files: 18 (incl. scripts, references)
Skills in repo: 115
Repo updated: Oct 6, 2026
First seen: Oct 7, 2026
Licence: MIT

At a glance

Refining a spec-driven pipeline any AI coding tool (Claude Code
SKILL.md covers Pipeline Overview, Loading Guide, Methodology Quick-Pick and Templates, plus 7 more sections
Runs Shell scripts from its folder
Droid) can follow

What it does

Spec Driven Development is an agent skill from magnus919/agent-skills. Design and run a Spec-Driven Development (SDD) pipeline for AI software factories — where structured specifications are the input, AI agents generate the code, and quality gates enforce correctness at each phase: SPECIFY → DECOMPOSE → IMPLEMENT → VERIFY → DELIVER. Use when building or refining a spec-driven pipeline any AI coding tool (Claude Code, Cursor, Hermes Agent, Devin, OpenHands, droid) can follow, or when you need spec quality gates, phase-gate verdicts, NFR encoding, or format translation. Do not use…

Its SKILL.md is about 3.8k tokens, which your agent loads only when the skill is triggered. The skill folder holds 21 other files, including scripts and reference files (for example `README.md`, `evals/evals.json` and `references/ai-factory-pipeline.md`). Compatibility notes: Tool-agnostic — methodology applies to any AI coding agent. Templates use markdown and Gherkin. Scripts require bash.

It sits in Development, covering Spec-driven development and Quality gates. The repository describes itself as: Curated collection of AI agent skills for Hermes and other agent frameworks. The licence is MIT.

When your agent uses it

Refining a spec-driven pipeline any AI coding tool (Claude Code
Droid) can follow
You need spec quality gates
Phase-gate verdicts

Example prompts

“/spec-driven-development”

Requirements

A Bash shell
Compatibility (from SKILL.md): Tool-agnostic — methodology applies to any AI coding agent. Templates use markdown and Gherkin. Scripts require bash.

What it can do on your machine

Read from SKILL.md and the folder at commit 96fbe07. It shows what the files ask for, not the result of running them.

Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Ships 2 files in scripts/ (Shell, from the files we listed), which the agent can run.
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Compatibility
Tool-agnostic — methodology applies to any AI coding agent. Templates use markdown and Gherkin. Scripts require bash.
From compatibility in the SKILL.md frontmatter.

Context cost

Spec Driven Development loads about 3.8k tokens when it runs, and up to ~18k if it reads all its reference files. Until then it costs about 194 tokens; SKILL.md has 1,650 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it: ~194
When it runs · the whole SKILL.md, loaded when a task matches: ~3.8k
With references · SKILL.md plus every file in references/, read only if the agent opens them: ~18k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); the scripts in this folder are not scanned.

SKILL.md

The full file from magnus919/agent-skills at commit 96fbe07, republished under its MIT licence (© magnus919). 1,650 words, ~3,817 tokens.

Download SKILL.mdSave it as .claude/skills/spec-driven-development/SKILL.md (or your agent's skills folder). This skill also uses 17 other files; get the full folder from GitHub.

name: spec-driven-development
description: Design and run a Spec-Driven Development (SDD) pipeline for AI software factories — where structured specifications are the input, AI agents generate the code, and quality gates enforce correctness at each phase: SPECIFY → DECOMPOSE → IMPLEMENT → VERIFY → DELIVER. Use when building or refining a spec-driven pipeline any AI coding tool (Claude Code, Cursor, Hermes Agent, Devin, OpenHands, droid) can follow, or when you need spec quality gates, phase-gate verdicts, NFR encoding, or format translation. Do not use for a single small change with a clear goal (classify first via bmad), for the control-plane protocol of intent contracts, autonomy gating, and failure routing around a pipeline (bmad), or for unvalidated problems (product-discovery).
compatibility: Tool-agnostic — methodology applies to any AI coding agent. Templates use markdown and Gherkin. Scripts require bash.
license: MIT
metadata.source: https://github.com/magnus919/agent-skills/spec-driven-development
metadata.spec-version: 1.2.0

Spec-Driven Development for AI Software Factories

A methodology for building software where specifications are the executable input to an AI code generation pipeline. The factory model: specs are blueprints, AI agents are the assembly line, verification is quality control, and gates catch defects before they compound.

Pipeline Overview

INCEPTION → [SPECIFY] → REVIEW → [DECOMPOSE] → REVIEW → [IMPLEMENT] → REVIEW → [VERIFY] → DELIVER
                 ↑         ↑          ↑            ↑           ↑           ↑          ↑         ↓
            Phase 1    Gate 1    Phase 2       Gate 2    Phase 3      Gate 3    Phase 4   Gate 4

Each phase passes through a gate before the next begins. A defect caught at Gate 1 costs minutes to fix; the same defect found at Gate 4 costs hours.

SDD Core Principles

Precision over clarity. A precise-but-dense spec is better than a readable-but-ambiguous one. The AI cannot ask for clarification — it implements one interpretation at random.

Completeness over brevity. Every missing acceptance criterion is a missing feature. Specifying an edge case upfront costs minutes; discovering it in production costs hours or days.

Testability over descriptiveness. An AC that cannot produce CLEAR PASS or CLEAR FAIL is not an AC — it's a hope.

Gates catch defects early. A Gate 1 (spec review) fix costs minutes. A Gate 4 (acceptance review) fix costs hours — the entire implementation may need to be discarded.

Spec is the single source of truth. Every downstream artifact traces back to the spec. Deviations are defects unless explicitly documented.

Spec IS the test (when possible). Gherkin-style ACs serve double duty as test cases. No separate test writing required.

Loading Guide

Reference	Load when	File
SDD Overview & Philosophy	You need to understand the why — the software factory metaphor, how SDD differs from traditional requirements, the core principle that specs are executable inputs not communication artifacts	`references/sdd-overview.md`
The AI Factory Pipeline	You need the full 5-phase pipeline with phase inputs, outputs, and transition rules — or you're designing a new pipeline from scratch	`references/ai-factory-pipeline.md`
Spec Quality Gates	You've written a SPEC.md and need to validate it before Gate 1 — the 7 gates that separate a good spec from a vague one	`references/spec-quality-gates.md`
Phase Gate Methodology	You're running a review gate (any of the 4) and need the decision criteria, verdict format, and escalation path	`references/phase-gate-methodology.md`
Methodology Selection Matrix	You're deciding which spec methodology (BDD, Formal, DbC, OpenAPI, ADRs) fits your context — when each applies and their AI-readiness ratings	`references/methodology-matrix.md`
NFR Encoding for AI Specs	You need to express non-functional requirements (performance, security, observability) in machine-readable format	`references/nfr-encoding.md`
Format Translation	You need to map between spec formats — Gherkin ↔ OpenAPI ↔ SPEC.md ↔ JSON Schema — or translate a human PRD into an AI-ready spec	`references/format-translation.md`
Critiques & Tradeoffs	You need to decide when not to use SDD — the honest limitations: spec bottleneck, GIGO, drift, over/under-specification, the formal methods tax	`references/critiques-and-tradeoffs.md`
Worked Example — Complete SPEC.md	You want to see a fully-realized specification to calibrate your output depth — shows proper AC format, edge case enumeration, NFR thresholds, data contracts, and assumptions for a password reset feature	`references/example-spec.md`

Methodology Quick-Pick

Not sure which spec methodology fits your situation? Use this quick reference table (load references/methodology-matrix.md for full depth):

Concern	Reach For	AI-Readiness	Format Produces
REST API contracts	OpenAPI	VERY HIGH	YAML/JSON specification
Event/message schemas (Kafka, RabbitMQ)	AsyncAPI	HIGH	YAML/JSON channel specs
Behavioral requirements (what the system does)	BDD / Gherkin	HIGH	`.feature` files with Given/When/Then
Interface correctness (pre/post/invariants)	Design by Contract	VERY HIGH	Assertions in code
Distributed system correctness (consensus, protocols)	TLA+ / Alloy	VERY HIGH (narrow scope)	Mathematical model
Architecture decisions (why we chose X)	ADRs	MEDIUM	Structured markdown
System structure (boxes-and-lines)	C4 Model	MEDIUM-HIGH	PlantUML / structured text
Raw stakeholder intent	User Stories	LOW (needs refinement)	"As a... I want..."

Composite approach: Most systems need 3-4 of these working together. REST APIs get OpenAPI, event streams get AsyncAPI, critical behavior gets Gherkin scenarios, and cross-team interface boundaries get DbC assertions.

Templates

Template	Pipeline Phase	File
SPEC.md	Phase 1 — Spec Authoring (SPECIFY). Write this first: problem, scope, user stories, ACs, edge cases, NFRs, data contracts	`templates/SPEC.md`
REVIEW.md	Gate 1-4 — Phase-Gate Review. Use at every gate transition: spec review, plan review, implementation review, acceptance review	`templates/REVIEW.md`
TASK-PLAN.md	Phase 2 — Work Decomposition (DECOMPOSE). Extract from an approved spec: task groups, dependency graph, per-task ACs, implementation directives	`templates/TASK-PLAN.md`
VERIFICATION.md	Phase 4 — Verification (VERIFY). After implementation: AC pass/fail matrix, compliance score, failure dossiers with remediation	`templates/VERIFICATION.md`

Scripts

Script	When to run	File
`spec-quality-check.sh`	After writing or editing a SPEC.md — validates all required sections exist (problem statement, scope, ACs, edge cases, NFRs, assumptions)	`scripts/spec-quality-check.sh`
`spec-to-tasks.sh`	After writing a TASK-PLAN.md — validates every spec AC has a covering task reference	`scripts/spec-to-tasks.sh`

Trigger Conditions

Load this skill when:

You're building a software factory — a system where AI agents produce code from structured specifications through a gated pipeline
You're designing or refining an AI code generation pipeline where specs drive implementation
You need to write a specification that an AI agent (not just a human) will consume
You're evaluating spec methodologies (BDD, Formal, OpenAPI-first) for a project
You need templates for SPEC.md, TASK-PLAN.md, REVIEW.md, or VERIFICATION.md
You're reviewing or verifying AI-generated code against its specification

Quick Reference: Pipeline Steps

Step	Action	Load This Reference	Produces
1	Write SPEC.md from template — problem, scope, stories, ACs, edge cases, NFRs	`references/spec-quality-gates.md` (validate before Gate 1)	`SPEC.md`
2	Run spec-quality-check.sh on SPEC.md	—	Validation report
3	Gate 1 — Review spec against quality gates, produce REVIEW.md	`references/spec-quality-gates.md`, `references/phase-gate-methodology.md`	`REVIEW.md` (APPROVED/CONDITIONS/REJECTED)
4	Decompose approved spec into TASK-PLAN.md — each task traces to a spec section	`references/ai-factory-pipeline.md` (Decompose phase)	`TASK-PLAN.md`
5	Gate 2 — Review task plan for dependency honesty, spec coverage	`references/phase-gate-methodology.md`	`REVIEW.md`
6	Implement each task — one task per agent session	—	Code/PR
7	Gate 3 — Verify implementation against spec (not code style)	`references/phase-gate-methodology.md`	`REVIEW.md`
8	Run verification against all ACs — produce VERIFICATION.md	—	`VERIFICATION.md`
9	Gate 4 — Review verification report, deliver only if no BLOCKING failures	`references/phase-gate-methodology.md`	Final approval

For deeper methodology context, load references/sdd-overview.md (philosophy) or references/ai-factory-pipeline.md (full pipeline detail with parallel execution).

Pipeline Mode & Entry Points

Show full SKILL.md (697 more words)Show less

Where to Enter the Pipeline

You don't always start at SPECIFY. Enter at the phase matching what you already have:

You Have This	Enter At	Start With
A vague idea, conversation, or PRD	Phase 1 — SPECIFY	`templates/SPEC.md` + `references/format-translation.md`
Approved product scope with interaction contracts	Phase 1 — SPECIFY	product-design-and-ux handoff + `templates/SPEC.md`
A clear, approved specification	Phase 2 — DECOMPOSE	`templates/TASK-PLAN.md` + `references/ai-factory-pipeline.md`
A spec + approved task plan	Phase 3 — IMPLEMENT	Task cards with per-task directives
Existing code needing verification	Phase 4 — VERIFY	`templates/VERIFICATION.md`

Which Pipeline Mode to Use

Not every change needs all 4 gates. Choose your mode:

Mode	When to Use	Gates to Run	Spec Depth
Full	Greenfield feature, multi-agent work, high-risk change, complex interfaces	All 4 gates	Full SPEC.md with ACs, NFRs, data contracts, edge cases
Lightweight	Simple bug fix, well-understood change, single-file edit	Gate 1 (light) → Implement → Gate 4 (light)	Single user story, 1-3 ACs, abbreviated NFRs
Minimal	Prototype, spike, exploration, throwaway code	None — skip formal gates	Mini-spec: 1 paragraph + 3 ACs. No NFR table, no contracts

Rule of thumb: If you know the fix in under 60 seconds and it touches one file, use Lightweight mode. If you're not sure what the right solution is, use Full mode — the gates will catch your mistakes early.

Gate Recovery & Revision

What happens when a gate rejects your artifact? The pipeline doesn't stop — it iterates.

The Revision Loop

Artifact submitted → Gate review → REJECTED or CONDITIONS
                                         ↓
                              Return to current phase
                                         ↓
                              Patch specific findings
                                         ↓
                              Resubmit for re-review
                                         ↓
                              APPROVED → next phase

How to Patch, Not Rewrite

Each finding identifies a narrow, fixable defect. Patch at the finding's location:

Finding Severity	Action	Example
BLOCKING	Fix immediately — gate cannot pass until resolved	Rewrite untestable AC with binary PASS/FAIL condition
CRITICAL	Must fix. Gate may pass with documented exception if ≤2 findings	Add missing edge cases to User Stories section
MINOR	Fix before next phase if feasible. Gate can pass with remediation plan	Add request/response schemas to Data Contracts
INFO	Note for future improvement. No action required for gate pass	Suggestion for alternative field naming

Re-Review Scope

After patching, the reviewer determines scope:

Full re-review: Required when REJECTED verdict. The entire artifact is re-evaluated, not just patched sections.
Targeted re-review: Possible with CONDITIONS verdict. Only the affected findings and surrounding context are reviewed.

Risk of partial fixes: Fixing only BLOCKING findings and ignoring CRITICAL ones guarantees re-rejection at the same gate. The CRITICAL findings that cost minutes to fix at Gate 1 will cost hours if caught at Gate 4.

Common Revision Patterns

Failure Pattern	Fix Strategy	Prevention
Untestable ACs (vague language like "should handle", "should be efficient")	Rewrite each AC with explicit Given/When/Then and binary outcome	Apply Gate 1 check before submitting
Missing edge cases	Add edge case enumeration per story — 3 minimum per story	Use the "five things that could go wrong" test from spec-quality-gates
Vague NFRs ("should be fast", "should be secure")	Replace with specific threshold + verification method	Use the "can I write a test for this?" test from nfr-encoding reference
Incomplete contracts (endpoint listed but no schemas)	Add full request/response schemas for every endpoint	Check Gate 5 before submitting
Scope creep (ambiguous in-scope items)	Tighten scope description and expand Out of Scope	Apply the "would someone include more than intended?" test

When not to use

A single small change with a clear goal — skip the spec pipeline and implement directly; classify the work first (see bmad).
You need the control-plane protocol around a pipeline — who owns intent, how work is classified, when autonomy is safe, how failure routes between layers: use bmad for intent contracts, work classification, autonomy gating, and failure routing. SDD supplies the spec format and gate mechanics; bmad supplies the protocol that runs the whole effort.
The problem itself is unvalidated — route to product-discovery before authoring a spec on top of an unexamined idea.

Tool-Agnostic Design

This skill describes the methodology, not a specific tool. The pipeline works with:

Claude Code — use CLAUDE.md as spec context, plan-then-implement mode
Cursor — Plan Mode + .cursorrules for spec context, Agent Mode for implementation
Hermes Agent — native SDD pipeline (authoring → review → decomposition → verification)
Devin / OpenHands — task-based implementation from spec-derived task plans
GitHub Copilot Workspace — issue-driven with spec as structured issue body
droid (Factory) — task cards from spec decomposition

The templates are format-agnostic (markdown). Adapt the handoff mechanism (CLAUDE.md, .cursorrules, AGENTS.md) to your tool.

Files

SKILL.md and 17 other files (scripts, references) in spec-driven-development of magnus919/agent-skills.

SKILL.md
README.md
evals/evals.json
references/ai-factory-pipeline.md
references/critiques-and-tradeoffs.md
references/example-spec.md
references/format-translation.md
references/methodology-matrix.md
references/nfr-encoding.md
references/phase-gate-methodology.md
references/sdd-overview.md
references/spec-quality-gates.md
scripts/spec-quality-check.sh
scripts/spec-to-tasks.sh
templates/REVIEW.md
templates/SPEC.md
templates/TASK-PLAN.md
… and 1 more

Open the folder on GitHubat commit 96fbe07

Compare with similar skills

Spec Driven Development next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Spec Driven Development compared with similar skills
Skill	Stars	Used in	Tokens	Auto-check	Licence	Repo updated
Spec Driven Development this skillmagnus919/agent-skills	113	—	~3.8k	Automated safety check: Pass	MIT	yesterday
BiSheng SDD Document Reviewdataelement/bisheng	12k	—	~717	Automated safety check: Pass	Apache-2.0	today
Task-Level Code Reviewdataelement/bisheng	12k	—	~652	Automated safety check: Pass	Apache-2.0	today
TLC Implementtech-leads-club/agent-skills	7k	—	~4.3k	Automated safety check: Pass	CC-BY-4.0	17 days ago
MoAI Foundation Coremodu-ai/moai-adk	1.2k	—	~5k	Automated safety check: Pass	Apache-2.0	today
OpenSpec Bulk Change ArchiverFission-AI/OpenSpec	71k	3 repos	~5.6k	Automated safety check: Pass	MIT	today

Similar skills

BiSheng SDD Document Review
dataelement/bisheng
Reviews BiSheng spec, design and tasks documents with checklists for PRD gaps, handover readiness and acceptance traceability, producing a report or an LGTM.
12k GitHub stars~717 tokensUpdated today
DevelopmentAuto-check passed
Task-Level Code Review
dataelement/bisheng
Runs a light convention check on one finished spec-driven task, choosing checks by task type and ending in pass, pass-with-notes or needs-fix.
12k GitHub stars~652 tokensUpdated today
DevelopmentAuto-check passed
TLC Implement
tech-leads-club/agent-skills
Turns an already-planned ticket or spec into a checklist, builds it, and has a fresh verifier agent prove each check independently.
7k GitHub stars~4.3k tokensUpdated 17 days ago
DevelopmentAuto-check passed
MoAI Foundation Core
modu-ai/moai-adk
Reference for MoAI-ADK's core development principles: TRUST 5 quality gates, SPEC-first domain-driven workflow, agent delegation and token budgeting.
1.2k GitHub stars~5k tokensUpdated today
Agent WorkflowsAuto-check passed
OpenSpec Bulk Change Archiver
Fission-AI/OpenSpec
Archives several completed OpenSpec changes in one operation, checking the codebase to resolve spec conflicts rather than archiving blindly.
71k GitHub starsUsed in 3 repos~5.6k tokens
DevelopmentAuto-check passed
Speckit Constitution
WeihanLi/WeihanLi.Common
Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
242 GitHub starsUsed in 11 repos~2.1k tokens
DevelopmentAuto-check passed

Questions about Spec Driven Development

What does Spec Driven Development do?

Design and run a Spec-Driven Development (SDD) pipeline for AI software factories — where structured specifications are the input, AI agents generate the code, and quality gates enforce correctness…. Spec Driven Development is an agent skill from magnus919/agent-skills. Design and run a Spec-Driven Development (SDD) pipeline for AI software factories — where structured specifications are the input, AI agents generate the code, and quality gates enforce correctness at each phase: SPECIFY → DECOMPOSE → IMPLEMENT → VERIFY → DELIVER.

When should I use Spec Driven Development?

Spec Driven Development fits situations like: refining a spec-driven pipeline any AI coding tool (Claude Code; droid) can follow; you need spec quality gates; phase-gate verdicts.

How do I install Spec Driven Development in Claude Code?

Run `npx skills add magnus919/agent-skills --skill spec-driven-development -a claude-code`. Or copy the skill folder (spec-driven-development in magnus919/agent-skills) into .claude/skills/spec-driven-development in your project. Claude Code loads it when a task matches its description.

How do I install Spec Driven Development in Codex?

Run `npx skills add magnus919/agent-skills --skill spec-driven-development -a codex`. Or copy the skill folder (spec-driven-development in magnus919/agent-skills) into .agents/skills/spec-driven-development in your project. Codex loads it when a task matches its description.

Can I use Spec Driven Development in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add magnus919/agent-skills --skill spec-driven-development -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/spec-driven-development, .gemini/skills/spec-driven-development, .github/skills/spec-driven-development and .opencode/skills/spec-driven-development in your project.

What does Spec Driven Development need to run?

Going by SKILL.md and its folder, Spec Driven Development needs a shell for the scripts in its folder. Our summary lists: A Bash shell. Compatibility (from SKILL.md): Tool-agnostic — methodology applies to any AI coding agent. Templates use markdown and Gherkin. Scripts require bash..

Does Spec Driven Development access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Spec Driven Development safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. The check reads SKILL.md only: the scripts in the folder are not scanned, so read them before running anything.

What licence does Spec Driven Development use?

Spec Driven Development is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Spec Driven Development use?

About 3.8k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 14k tokens, read only when the agent opens those files.

What are the alternatives to Spec Driven Development?

Skills that share tags, products or a category with Spec Driven Development: BiSheng SDD Document Review (dataelement/bisheng, 12k stars), Task-Level Code Review (dataelement/bisheng, 12k stars), TLC Implement (tech-leads-club/agent-skills, 7k stars) and MoAI Foundation Core (modu-ai/moai-adk, 1.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Spec Driven Development?

magnus919 (a GitHub user) maintains it in magnus919/agent-skills, which has 113 GitHub stars. The repository holds 115 skills in this directory. The repository was last updated on October 6, 2026.

Source: magnus919/agent-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.

Install Spec Driven Development

Facts

At a glance

What it does

When your agent uses it

Example prompts

Requirements

What it can do on your machine

Tool permissions

Runs code

Network

Credentials

Compatibility

Context cost

Safety

SKILL.md

Spec-Driven Development for AI Software Factories

Pipeline Overview

Loading Guide

Methodology Quick-Pick

Templates

Scripts

Trigger Conditions

Quick Reference: Pipeline Steps

Pipeline Mode & Entry Points

Where to Enter the Pipeline

Which Pipeline Mode to Use

Gate Recovery & Revision

The Revision Loop

How to Patch, Not Rewrite

Re-Review Scope

Common Revision Patterns

When not to use

Tool-Agnostic Design

Files

Compare with similar skills

Similar skills

More from magnus919/agent-skills

Related

Questions about Spec Driven Development