specdd Guide: Spec-Driven Development as a Single Agent Skill

If the spec-driven ecosystem has a minimum viable option, it's specdd: spec-driven development packaged as a single SKILL.md file. No CLI, no config files, no slash commands, no dependencies. You drop one skill file into your agent, and the agent knows how to run a spec-driven workflow.

Every other tool in this cluster — Spec Kit, OpenSpec, BMad, Spec Kitty — is a system you adopt. specdd is a skill you try. For the developer who wants to feel what spec-driven coding actually changes before committing to a framework, it's the fastest possible on-ramp.

The workflow inside the skill

The skill defines a compact pipeline that runs inside any agent conversation:

1. Triage — the agent assesses the request: small and clear, or big and fuzzy.
2. Interview — for anything non-trivial, the agent asks 2–5 clarifying questions before writing anything. This single step eliminates the most common spec failure: building against an assumed requirement.
3. Tech-free spec — the agent writes the spec in plain, technology-free language: what and why, no implementation details. Scales from a 5-line mini-spec to a multi-file project spec.
4. Two-minute technical plan — a deliberately short design: approach, files touched, risks.
5. Build & verify — implementation with a production-grade checklist: tests, error paths, edge cases.

The "tech-free spec" step is the heart of it — the same discipline GitHub Spec Kit enforces with a checklist (strip implementation details from the spec), delivered as a conversation skill rather than a gate.

Where specdd fits

Choose specdd when:

• You want to feel spec-driven coding before choosing a framework. Fifteen minutes, zero setup.
• You're a solo developer who won't maintain a workflow system — a skill file is a skill file.
• You work across agents (Claude, Codex, Copilot, Cursor, Windsurf, Gemini CLI all support skills) and want one workflow everywhere.
• You're evaluating the methodology for your team and want a zero-cost proof of concept.

Skip it when:

• You need versioned spec artifacts in the repo, delta tracking, or a review lane — that's what the real frameworks do. OpenSpec if you want light, Spec Kit if you want standard, Spec Kitty if you want governance.
• You need enforcement — a skill is advice the agent follows; it has no gates it can't talk its way around.
• You're running a team with multiple agents on one codebase — the team-oriented frameworks bring the coordination.

The spectrum of spec-driven adoption

specdd is the "try it" end of a spectrum that runs all the way to governed factories:

| | specdd | OpenSpec | GitHub Spec Kit | Spec Kitty | |---|---|---|---|---| | Form | 1 skill file | CLI + 4 commands | CLI + 9 slash commands | CLI + kanban + worktrees | | Setup | None | ~5 min | ~30 min | Moderate | | Artifacts | Conversation specs | Delta specs in repo | Spec/plan/tasks in repo | Lifecycle lanes in repo | | Governance | None (skill-level) | None | Constitution gates | Accept gates + review lane | | Best for | Trying SDD today | Brownfield iteration | The standard workflow | Visible governance |

The complete spec-driven coding guide lays out the whole spectrum, and the spec-driven vs vibe coding comparison makes the case for why even the lightest version of this is better than raw prompting.

Getting started

Grab the SKILL.md from the specdd repo and drop it into your agent's skills directory. Next task, invoke it. Watch it ask you 2–5 questions before touching code — and notice how much better the result is when the requirement is pinned down first. If that feels good, the frameworks are waiting.