From specdd
Spec-driven development orchestrator that turns vague, top-of-mind feature requests into production-grade specifications before any code is written. ALWAYS use this skill whenever the user describes a feature, change, capability, screen, flow, or new component in plain language — even if they don't explicitly ask for a spec. Triggers on phrases like "build me", "make me", "add a feature", "I want to", "help me create", "implement", "let's build", "I need a", "can you make", "create a screen/page/component", or any new-feature request that lacks complete requirements (missing user stories, acceptance criteria, edge cases, error/empty/loading states, accessibility, or non-functional requirements). Interviews the user to fill gaps, applies UX/UI common sense, produces a structured spec + plan + tasks, then implements against the spec. Use this BEFORE writing any code for non-trivial features. Skip only for true one-liners (rename a variable, fix a typo, answer a research question) or work that is purely investigative.
How this skill is triggered — by the user, by Claude, or both
Slash command
/specdd:specddThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
User requests for features are incomplete by design — the user gives you the top-of-mind 30%, not the full spec. Coding from that ships things that compile but miss the actual intent, skip the boring-but-critical states (loading, empty, error, edge), and feel unpolished.
User requests for features are incomplete by design — the user gives you the top-of-mind 30%, not the full spec. Coding from that ships things that compile but miss the actual intent, skip the boring-but-critical states (loading, empty, error, edge), and feel unpolished.
specdd inverts that: you produce a spec the user agrees with before writing code. The spec captures intent, the user, the UX, edge cases, and non-functional requirements. The user keeps creative control; you stop guessing.
Not waterfall. The spec is small, agent-readable, revisable. Goal is alignment, not bureaucracy.
Use it for any feature, screen, flow, component, API, change, or capability — even a one-line request.
Skip for: one-liners (rename, typo), pure Q&A or research, bugs with clear repro, or continuing in-progress work that already has a spec.
If unsure, use it. Under-use is the more common mistake.
| Scope | Signal | Artifacts |
|---|---|---|
| Quick | Single component, <30 min, no new surface area | Inline mini-spec (5–8 bullets) in chat. No files. |
| Feature | New UI / flow, 1–4 hours | spec.md + plan.md inline or as files. Skip tasks. |
| Project | Multi-day, multiple files/services | spec.md + plan.md + tasks.md as files in specs/<feature-name>/. |
User can override: "just a quick one" or "do this properly".
1. TRIAGE → scope, scale, skip-or-not
2. INTERVIEW → fill gaps the user didn't think to mention
3. SPEC → what & why (user-facing, no tech)
4. PLAN → how (tech approach, files, decisions)
5. TASKS → ordered, testable work units (Project scope only)
6. BUILD & VERIFY → implement against spec; run production-grade checklist before "done"
You don't ask permission to follow this workflow — it's the default. You DO surface the spec and plan for confirmation before building.
specs/ first if it exists.State triage briefly: "Treating this as a Feature — drafting a spec, then we'll build."
Heart of the skill. Ask the few right questions to fill gaps — not a 20-question form.
Rules:
Cover the gaps the user didn't already address, in priority order:
See references/interview-playbook.md for question templates by request type.
Use references/spec-template.md. The spec is user-facing and tech-free — no frameworks, libraries, file names, or function names. If you're writing useState or POST /api/, you're in the Plan.
Show spec to user. Wait for explicit "looks good" / "ship it". Revisions are normal — expect 1–3 rounds for non-trivial features.
Use references/plan-template.md. Covers stack choices, file-level breakdown, key decisions with one-line rationale, alternatives considered, risks. Under 2 minutes to read. If longer, split the feature.
Use references/tasks-template.md. Each task: independently completable in one agent turn, has an observable "done" signal, has explicit dependencies.
For Quick or Feature scope, the agent's todo list is enough — skip the file.
Implement against the spec. While building:
Before declaring done, run the checklist in references/production-checklist.md — empty/error/loading states, a11y, keyboard, mobile, edge inputs, observability. Report what you verified and what you didn't: "Verified items 1–15, skipped i18n (single-locale), didn't test screen-reader behavior end-to-end."
Push back before building, not after. UX defaults this skill assumes:
Five-states rule. Every screen / component / feature has these. If the spec doesn't address all five, it's incomplete:
Other defaults baked in. State them when relevant; the user can override:
Esc closes; Enter submitsprefers-reduced-motion; animations short (150–250ms) and ease-outreferences/examples/example-quick-feature.md — Quick scope, inline onlyreferences/examples/example-feature-spec.md — Feature scope with spec + planreferences/examples/example-project.md — Project scope with filesRead the relevant example if unsure what the output should look like at a given scope.
Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub unboundinnov/specdd --plugin specdd