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 agentmods add skills/rubenzarroca/sdd-plugin/sdd-specifynpx skills add rubenzarroca/sdd-plugin --skill sdd-specifygit clone --depth 1 https://github.com/rubenzarroca/sdd-pluginWrote 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/rubenzarroca/sdd-plugin/sdd-specify)<a href="https://agentmods.dev/skills/rubenzarroca/sdd-plugin/sdd-specify"><img src="https://agentmods.dev/badge/skills/rubenzarroca/sdd-plugin/sdd-specify.svg" alt="Measured on agentmods" 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 | $0.00189 | $0.05360 |
| Opus 5 | $0.00095 | $0.02680 |
| Sonnet 5 | $0.00038 | $0.01072 |
| Haiku 4.5 | $0.00019 | $0.00536 |
Grade A, and why
sdd-specify 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 5d 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 — 374 lines — stays where its author put it; the contents beside it link to each section on GitHub.
SDD Specify — Feature Specification Generator (11-Section Methodology)
A feature spec is the bridge between product vision (PRD) and implementation. It defines everything an LLM or developer needs to build a feature correctly on the first pass: what it does, how it behaves, what data it touches, how components communicate, and what happens when things go wrong.
Integrated Coaching Philosophy
This skill has a dual purpose: it generates specs AND teaches the user to write better specs over time. The coaching follows constructivist pedagogy — learning happens in the moment of need, within the real task, not in a separate module.
How Coaching Works
Claude monitors everything the user provides during the specify workflow. When it detects a weakness, it applies scaffolding: a brief, contextual intervention that teaches a concept by applying it to the user's actual problem. The user learns without knowing they're being taught.
Scaffolding triggers and responses:
| What Claude detects | What Claude does |
|---|---|
| Vague requirement ("must be fast", "should handle many users", "needs to be secure") | Offers a concrete, quantified alternative using the user's own data. Example: "With 500 leads/week, a P95 response time of 500ms would keep the commercial team flowing. Want me to set that as the threshold?" |
| Missing edge case (no error handling mentioned for external dependencies) | Asks a scenario question. Example: "What should happen if BigQuery is down when a lead score is requested? Options: serve stale score with a warning, queue for retry, or return a default score." |
| Untestable acceptance criterion ("the UI should feel intuitive") | Reframes as testable. Example: "'Feel intuitive' is hard to test. Could we say 'a new user completes the main flow in under 3 clicks without documentation'? That's verifiable." |
| No non-goals defined | Prompts with a concrete example. Example: "What should this feature NOT do? For instance, should the scoring engine also handle lead nurturing, or is that out of scope?" |
| Data model gaps (referencing data without defining where it lives) | Makes the implicit explicit. Example: "You mentioned 'budget declared by the lead.' Where does this live? Is it a field in the CRM, a form input, or derived from behavior? This matters for the data model." |
| Ambiguous relationship between entities | Asks for cardinality. Example: "Can a lead belong to multiple promotions simultaneously, or is it always one promotion per lead? This changes the data model significantly." |
| Missing API contract details | Asks about the contract. Example: "You've described what the scoring endpoint does, but what should it return? A score number? A tier? The full breakdown? Defining the response shape now prevents refactoring later." |
| Security or compliance blind spot | Flags the gap. Example: "This feature processes phone numbers and emails. Does it need to comply with GDPR? If so, we need a consent field and a data retention policy in the spec." |
| Hardcoded values that should be configurable | Suggests configurability. Example: "You said the hot threshold is 75. What if that changes next quarter? If we make it configurable via a settings table, the team can adjust without a deploy." |
| Over-engineering (adding complexity not justified by requirements) | Pulls back. Example: "You're describing a real-time ML pipeline, but with 500 leads/week a simpler weighted scoring formula would work. We can always upgrade to ML later if the volume justifies it. Want to start simpler?" |
| User struggles with technically dense sections (data models, API contracts) — gives vague answers, says "I don't know", or defers entirely | Shift from "ask the user to provide" to "propose and choose" using AskUserQuestionTool. Instead of a conversational wall of text, present 2-3 concrete options as selectable choices — label with the option name, description with a one-sentence trade-off, and markdown preview with the technical details. Example: instead of asking "What should the response shape be?", present options like "Simple (score only)" / "Detailed (score + breakdown)" / "Flexible (configurable fields)" with preview showing the JSON shape for each. The user picks one; if none fit, they select "Other". If the user still can't choose, make the decision and note it in Open Questions for later review. |
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.
- 5d ago First seen · 374 lines · 189 tokens per session scan A 117d94d859ed
sdd-specify is a skill published in the GitHub repository rubenzarroca/sdd-plugin (6 stars, last pushed 6mo ago), licensed MIT. It adds 189 tokens to every session and 5,360 once invoked, about $0.0009 per session on Opus 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-08-31.
Other skills, from other repositories
fix
Use to drive a bug fix from first report through close, with a "why didn't we catch it?" loop at the end. Triggers — "/engineer.fix", "a bug came in", "this is broken", "a user reported X", "there's a defect", "we have a regression", "this needs a fix", "another report", "more issues", "still failing", "validation…
next
Use at the start of a work session, or any time the question is "what should I pick up now" across the whole project. Triggers — "/engineer.next", "what's next", "what should I work on", "what should I do next", "where do I pick up".
post-merge
Use immediately after a PR is merged to clean up the local feature branch and resync main. Triggers — "/engineer.post-merge", "did we merge", "did we push", "PR merged", "post-merge cleanup", or right after a gh pr merge succeeds in the same session.
crap-analyzer
Use to produce a risk-based refactor + test plan for recently-changed code on a diff/branch/PR by computing CRAP (complexity × untested) on changed methods. Multi-language — TypeScript, JavaScript, Python, Java, Kotlin, Go, Ruby, C#, Rust, PHP — auto-discovers how the repo generates coverage. Triggers …
session-summary
Use at the end of a work session on a DAE feature, so the next session picks up cleanly. Triggers — "/engineer.session-summary", "wrap up the session", "write the session log", "I'm stopping for the day".
onboard
Use to bring a project into the DAE methodology, or to check an onboarded project for gaps. Triggers — "/engineer.onboard", "onboard this project", "set up DAE here", "adopt the methodology", or when a DAE skill fails because no manifest exists.