Spec Kit vs Kiro vs Claude Code: Picking an SDD Setup by Tradeoff, Not Hype

Developers comparing spec-driven setups in 2026 usually aren’t asking which model is smartest. They’re asking which workflow keeps an AI agent aligned without burying them in ceremony. Spec Kit, Kiro, and Claude Code custom workflows all implement specify-plan-tasks-implement-validate — but they bet differently on portability versus integration depth.

Portable markdown specs versus integrated IDE loops: the axis the tool choice turns on

Spec Kit, Kiro, and Claude Code custom workflows all implement specify-plan-tasks-implement-validate — but they bet differently on portability versus integration depth. This buyer’s guide compares them along eight dimensions: what each option costs, and which setup fits which team. For the prior question — whether the feature deserves a spec at all — see SDD vs Vibe Coding.

The Real Axis: Portable Specs or Integrated Loop

  Portable                              Integrated
  --------                              ----------
  Spec Kit, Claude Code skills,         Kiro IDE, Tessl
  OpenSpec, Superpowers
        |                                       |
        v                                       v
  Markdown specs in Git,                Editor-native loop,
  any agent executes                    environment executes

Kiro is integrated. Spec Kit is portable. Claude Code workflows are hackable. Bad specs make every agent worse regardless of wrapper; good specs travel across tools.

Eight Dimensions Before Picking

Name what is being optimized before comparing tools — the same feature feels effortless or bureaucratic depending on team size, codebase age, and review needs:

• Portability — plain markdown specs working with next quarter’s agent, or formats tied to one IDE, cloud, or vendor?
• Setup friction — minutes from “try SDD” to a working specify-plan-tasks loop?
• Spec quality — does the tool produce precise requirements and acceptance criteria, or just long documents? Structure helps; volume doesn’t.
• Task execution — reviewable slices, parallelizable tasks, resistance to fifty-item task explosions?
• Review checkpoints — human gates between specify, plan, tasks, implement? SDD without review is slower vibe coding.
• Repository grounding — does planning read conventions, decision records, AGENTS.md, and existing code first? Ungrounded agents reinvent architecture.
• Team collaboration — shared spec review in pull requests, mixed agents without process rewrites?
• Lock-in — cost of switching editors, models, or vendors in six months?

GitHub Spec Kit: Portable Scaffolding

Spec Kit is an open-source CLI that scaffolds the loop into the repo and hands execution to the agent already in use. The specify CLI drops templates, slash commands, and a conventional layout, running constitution, specify, clarify, plan, tasks, implement — with an explicit clarify step resolving ambiguity before architecture work.

Its defining advantage is agent independence: one markdown spec set, 30+ supported executors, swap agents without rewriting process. Default pick for teams wanting SDD without a vendor bet — strong for greenfield features and multi-agent shops.

AWS Kiro: The Guided IDE

Kiro is AWS’s spec-native IDE on a VS Code fork: a prompt generates requirements.md (EARS-style), design.md, and dependency-sequenced tasks.md before production code, all as first-class UI objects. Its exclusive trick is Agent Hooks — event-driven automations updating tests, docs, or related artifacts as implementation changes. That bidirectional loop is what Spec Kit lacks: Spec Kit specs stay static until a human edits them.

The price is ecosystem depth: editor lock-in, Bedrock-backed models, credit-metered billing. Acceptable for AWS-native enterprise teams; heavier for solo developers and multi-editor shops.

Claude Code Skills: Hackable and Undisciplined

Claude Code ships no official SDD product — the pattern lives in custom commands, skills, and repo-local templates, with older .claude/commands/*.md folded into the Skills mechanism. Port a Kiro-style three-file layout, mirror Spec Kit phases with slash commands, or invent a minimal per-repo loop; CLAUDE.md carries always-on context while skills load on demand.

Lightest and most hackable — and entirely self-policed. Nothing forces clarify or review gates unless built in, and copied skills rot back into unstructured prompting under schedule pressure. Works when skills are treated like code: versioned, reviewed, maintained.

Superpowers: Enforcement as a Package

Superpowers targets exactly the discipline gap above: an open-source skills bundle (brainstorming, writing-plans, subagent-driven development, strict TDD, code review) that triggers automatically as mandatory workflow rather than optional suggestion. Cross-agent manifests (Claude Code, Cursor, Codex, Gemini CLI, Copilot CLI, and more) make it the middle ground between DIY skills and Kiro — enforced loop, own editor, no vendor spec format. Full walkthrough in the Superpowers post.

The Rest of the Field

• OpenSpec (Fission AI): change-centric, fewer files than Spec Kit, lower token usage; wins on brownfield iteration without an 800-line planning phase.
• BMAD-METHOD (community): multi-agent role simulation (owner, architect, developer, reviewer); powerful for large greenfield efforts, heavy everywhere else — ceremony pays only when coordination pain is already acute.
• Tessl (commercial, beta): spec as literal source of generated code, output marked derived, hand-edits discouraged. Strongest spec-as-source stance, highest lock-in.
• Spec Kitty and similar scaffolds: between OpenSpec and Spec Kit on weight; templates without the full GitHub toolchain.

One pattern across all: process helps where ambiguity is expensive and hurts where feedback speed matters more. Match tool weight to task size, not hype.

Which Setup for Which Team

• Solo dev, existing codebase, small features — Claude Code skills or OpenSpec: short requirements, minimal tasks, one review checkpoint. No full Spec Kit tree for a fifty-line change.
• Skipping your own review gates — Superpowers over a custom skill: trade some tuning for an enforced loop independent of daily discipline.
• Solo dev, greenfield, multiple sessions — Spec Kit or a maintained SDD skill: durable artifacts over IDE hand-holding.
• Small team, mixed editors — Spec Kit: markdown in Git, PR-reviewed, each developer’s agent executes.
• Enterprise, AWS-native, compliance pressure — Kiro: guided artifacts, traceability, hooks. Tooling eases audit trails; it doesn’t replace them.
• Brownfield bugfixes — OpenSpec or a lightweight skill. Full ceremony per bugfix feels like waterfall.
• Greenfield product, many agents — Spec Kit: portability beats IDE polish when Copilot, Claude Code, and Cursor touch one repo.

Condensed:

A rough routing sketch:

  Need a new IDE?
    YES + AWS OK ............ Kiro
    NO ---> Team uses many agents?
              YES ........... Spec Kit
              NO ---> On Claude Code already?
                        YES . Custom SDD skill (or Superpowers)
                        NO .. Spec Kit
  Brownfield small change? .. OpenSpec or minimal spec

What Decides Success Anyway

Tool choice trails artifact quality. Vague Kiro acceptance criteria drift like a sloppy prompt; a fifty-task Spec Kit plan feels like waterfall under any agent. The portable practices: specs reviewable in one sitting, explicit non-goals, human-readable diffs per task, validation against acceptance criteria before merge, spec updates when implementation finds a better path.

Pick the shallowest setup that removes ambiguity for the feature at hand, and add structure when coordination pain appears — not when a comparison post says so. The developers getting value from SDD write specs worth implementing, then let any tool execute against them.

Which SDD setup survived your team’s reality — portable specs or an integrated loop? Share what stuck in the comments below!