Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add juanmhidalgo/claude-plugins --skill spec-driven-developmentgit clone --depth 1 https://github.com/juanmhidalgo/claude-pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/juanmhidalgo/claude-plugins/spec-driven-development)<a href="https://agentmods.dev/skills/juanmhidalgo/claude-plugins/spec-driven-development"><img src="https://agentmods.dev/badge/skills/juanmhidalgo/claude-plugins/spec-driven-development/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/juanmhidalgo/claude-plugins/spec-driven-development"><img src="https://agentmods.dev/badge/skills/juanmhidalgo/claude-plugins/spec-driven-development.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00048 | $0.03910 |
| Opus 5.5 | $0.00019 | $0.01564 |
| Sonnet 5.5 | $0.00010 | $0.00782 |
| Haiku 4.5 | $0.00005 | $0.00391 |
Grade A, and why
spec-driven-development scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 250 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spec-Driven Development
When to Use
- Starting a new feature or project
- Requirements are ambiguous or incomplete
- Change touches multiple files or modules
- Task would take more than 30 minutes to implement
- About to make an architectural decision
The Gated Workflow
Do not advance until the current phase is validated by the user.
SPECIFY ──→ [PLAN ──→ TASKS] ──→ IMPLEMENT
│ │ │ │
▼ ▼ ▼ ▼
Review Review Review Review
PLAN and TASKS are optional. The default path is Specify, then /feature-dev:explore-plan writes the step-level plan from the code. Run them (/feature-dev:spec --with-tasks) only when no explore-plan run will follow — otherwise the spec carries a second plan that explore-plan re-derives with different numbering, and the two drift.
Each gate ends with a short review brief (decided / assumed / unverified claims about the code / out of scope — the format is in /feature-dev:spec), not the whole artifact re-printed: the user approves from what they read in the chat.
Phase 1: Specify
The first interaction is one scope question, asked alone (AskUserQuestion, a single question) before assumptions and before exploring any code: which repos and components are in, what is explicitly out, with a recommended option inferred from the description (the multi-repo detection below feeds it). Scope sizes everything after it, and a scope question bundled with others gets answered last; scope that moves after approval means a re-plan. What the answer rules out becomes the spec's ## Non-Goals.
Then surface assumptions, in their own round-trip: one AskUserQuestion call with one question per assumption (up to 4), each a single decision with the assumption as the recommended option and a concrete alternative beside it. A single question that lists every assumption with "confirm all / correct some" makes the answer all-or-nothing, and a correction means typing which item and how. Facts about the code are checked, not asked.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago Changed · -3 lines b3f3db362d0d
- 21d ago Changed 129a2db8416c
- 25d ago Changed · +12 lines c0aa8237f70e
- 26d ago Changed · +13 lines 20a42675b4dd
- 1mo ago Changed 3752f8c92637
- 1mo ago Changed · +20 lines 64e7bb5386b9
- 1mo ago First seen · 208 lines · 48 tokens per session scan A 4a7b5a24ec70
spec-driven-development is a skill published in the GitHub repository juanmhidalgo/claude-plugins (8 stars, last pushed yesterday), licensed MIT. It adds 48 tokens to every session and 3,910 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
project-specification
Transforms project briefs into testable specifications with user stories and acceptance criteria. Use after brainstorming, before planning.
write-prd
Write PRD — Product Requirements Documents with structured 8-section templates, user stories, acceptance criteria, and value proposition validation. Use when writing PRDs, defining product requirements, creating user stories with INVEST criteria, or building go/no-go decision frameworks.
openspec-bulk-archive-change
Archive multiple completed OpenSpec changes at once. Use when archiving several parallel changes. Also use for a plural archive request - "openspec bulk-archive", "opsx bulk-archive", "openspec archive all", or "openspec archive these changes".
openspec-archive-change
Archive a completed OpenSpec change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete. Also use when the user says "openspec archive" or "opsx archive".
comet-classic
A Chinese-language workflow guide for starting or resuming a structured software change using OpenSpec and Superpowers.
comet-native
A workflow for managing Native changes in Comet, where requirements, progress, and acceptance results are saved in project files. It uses the Comet command-line runtime to move through defined work stages.