Spec Kit or Kiro? An SDD Tool Selection Guide

Spec-driven development (SDD) has emerged over the past year as a counterweight to "vibe coding": write the spec first, then have an AI agent implement it. GitHub's open-source Spec Kit and AWS's closed-source Kiro are the two most mature tools for this approach, but with opposite philosophies: one is a portable CLI scaffold layered on your existing agent, the other an integrated product with its own IDE-to-CLI surfaces. A third option may already be in your hands: Claude Code's own CLAUDE.md + skill + subagent mechanism gives similar discipline with no extra setup. This guide starts with a 60-second decision table, then goes deeper into setup steps, notation differences, real commands, and pricing.

💡 Pro Tip: Don't decide without trying Spec Kit and Claude Code's built-in spec flow side by side on the same feature — both take only a few minutes to set up, but the difference in "feel" only shows up on a real task.

Table of Contents

• The 60-second decision table
• The adoption asymmetry — what 138K vs 4.3K stars means
• Spec Kit: setup, flow, portability
• AWS Kiro: EARS notation, IDE integration, AWS dependency
• Claude Code's built-in path
• Trying the same feature across all three tools
• Who should choose which
• FAQ
• Should I choose GitHub Spec Kit or AWS Kiro?
• Which AI coding tools does Spec Kit work with?
• What is Kiro's EARS notation?
• How do you do spec-driven development inside Claude Code?
• What's the difference between Spec Kit's short path and full path?
• How does Kiro's pricing compare to Spec Kit's?
• Conclusion
• Sources

The 60-second decision table

We compare the three tools across five axes: openness (license), lock-in risk, requirement notation, agent support, and a maturity signal (GitHub stars, pulled live as of 2026-09-23).

Short summary: Spec Kit is "a portable scaffold layered on top of your existing agent," Kiro is "an integrated product that runs a single agent harness across IDE, CLI, web, and mobile surfaces," and Claude Code's built-in path is "a hackable minimal framework."

The adoption asymmetry — what 138K vs 4.3K stars means

Figures pulled live from the GitHub API on 2026-09-23: github/spec-kit has 138,408 stars, last pushed 2026-09-22T21:44:09Z — meaning a daily commit stream was still flowing right up to measurement day. The kirodotdev/Kiro repo, meanwhile, has 4,328 stars, last pushed 2026-09-15T14:31:12Z; no new pushes for over a week up to measurement day. The ratio is roughly 32x (138,408 / 4,328 ≈ 31.97).

One nuance is worth not skipping: Kiro's GitHub repo's Releases tab is completely empty — the product ships as binaries via kiro.dev/downloads. So kirodotdev/Kiro isn't the product's source code; it largely functions as an issue tracker and community repo — the "Report a bug" link points there too. The 138K-to-4.3K comparison thus sets "open-source project popularity" against "a closed-source product's community-repo popularity" — not identical measures, but still a real signal: Spec Kit has built a GitHub-native ecosystem, Kiro hasn't.

The trend line confirms it: on the independent star-history.com chart, spec-kit's growth traces a steady slope spread across months, not a single news spike. So reading the 138,408 pulled from the API on 2026-09-23 as "inflated by one announcement day" would be wrong — the curve shows continuity. Don't, however, read three-digit-precision values off such charts; they show trend, not data labels. For an exact number, pull it directly from api.github.com, with the date attached.

The license difference also widens the asymmetry: spec-kit is MIT-licensed, while the Kiro repo's API response shows license: null — meaning there's no explicit license declaration at the repo level.

Spec Kit: setup, flow, portability

Spec Kit isn't an npm package — it's a Python package, installed via PyPI with uv:

1# Install (official quickstart)
2uv tool install specify-cli
3 
4# Start a new project, pick the agent you prefer
5specify init taskify --integration copilot

After setup, the project moves through 5 commands on the short path:

1/speckit-specify    # 1. What are you building — produces spec.md
2/speckit-plan        # 2. How will you build it — plan.md
3/speckit-tasks        # 3. Break into a task list — tasks.md
4/speckit-implement    # 4. The agent applies tasks in order
5/speckit-converge     # 5. Verifies consistency between spec and code

For production features, the "full path" adds three more quality gates on top of these five: /speckit-clarify, /speckit-checklist, /speckit-analyze — so you don't move to planning while the spec is ambiguous, and you don't break the plan into tasks while it's inconsistent. In the official quickstart, the full path is laid out as nine steps, together with /speckit-constitution, which runs once per project:

1/speckit-constitution   # 1. Once per project: base rules (security, architecture, documentation)
2/speckit-specify        # 2. What will be built
3/speckit-clarify        # 3. Resolve ambiguities (e.g. card behavior, comment permissions)
4/speckit-plan           # 4. Choose the tech stack
5/speckit-checklist      # 5. Validate the spec
6/speckit-tasks          # 6. Break the work into pieces
7/speckit-analyze        # 7. Consistency audit
8/speckit-implement      # 8. Apply tasks in dependency order
9/speckit-converge       # 9. Verify code against spec/plan/tasks

Two details in this chain make a practical difference. /speckit-implement executes the tasks in tasks.md in dependency order, and before implementing it reads the state of the checklist boxes as a gate — if there's an unchecked item, it asks before proceeding; it doesn't modify the checklist files itself. /speckit-converge, meanwhile, checks the codebase against the spec, plan, and tasks, and if it finds a gap, adds new tasks to tasks.md — you repeat implement and converge until you get a "Converged" report.

Behind the portability claim are concrete numbers: Spec Kit's official site lists 38 agent/editor integrations ("Copilot, Gemini, Codex, Kilo Code, Zed, Claude, Forge, Kiro, and more... No lock-in") along with 157 community plugins (from 90+ authors) and 33 ready-made presets. The latest release is v1.0.10, published on 2026-09-22.

AWS Kiro: EARS notation, IDE integration, AWS dependency

Kiro isn't just a CLI; per its official documentation's own definition, it's built around "a single unified agent harness," with an integrated product spanning IDE, CLI, web, and mobile (iOS) surfaces — the same agent, the same sessions, and the same configuration apply on every surface. Spec Kit, by contrast, is a CLI scaffold layered on top of your existing agent; the difference isn't "CLI vs. IDE," it's the question of "are you adopting the whole product, or just adding the process layer." Kiro has requirements written in EARS notation (Easy Approach to Requirements Syntax) instead of free-form Markdown — the pattern looks like this:

1WHEN a user submits a form with invalid data
2THE SYSTEM SHALL display validation errors next to the relevant fields

The point of this pattern is for both humans and AI agents to read and interpret the same sentence in exactly one way — it reduces the risk of an "ambiguous requirement."

Kiro's Feature Specs flow offers two variants:

• Requirements-First: Requirements → Design → Tasks (the classic order, with an approval gate at each stage)
• Design-First: Design → Requirements → Tasks (for those who want to nail down the architecture first, then come back to requirements)

For quick, single-session tasks there's a third mode too: Quick Spec, which runs the three phases automatically without approval gates.

Pricing is credit-based — packages listed on the official pricing page (kiro.dev/docs):

The Free tier includes Claude Sonnet 4.5 and open-weight models; on paid plans the cost per credit is fixed ($0.02), only the package size changes — overage credits are priced at double ($0.04).

AWS dependency isn't an abstract risk, it's an announced roadmap: per AWS's own DevOps blog, Amazon Q Developer IDE extensions and paid subscriptions will reach end of support on April 30, 2027, with customers given twelve months to migrate to Kiro. The same announcement calls Kiro "an agentic development environment (IDE, CLI) built from the ground up for spec-driven development," carrying over Q Developer's agentic coding, inline chat, terminal integration, and MCP support. Models are diverging too: as of May 29, 2026, Opus 4.6 is no longer offered in Q Developer Pro — the newest coding models ship only through Kiro. Kiro's /docs/upgrade-guides/migrating-from-q-developer/ guide is the operational counterpart of this migration.

A secondary source reports that in August 2025, Kiro tried a credit model split into "vibe request" and "spec request," and a metering bug unexpectedly drained users' credits, drawing sustained community backlash (codemyspec.com). The single-credit model in effect as of 2026-09-23 is the simplified aftermath of that walk-back.

Claude Code's built-in path

Claude Code provides spec-like discipline without installing a separate SDD tool — through three building blocks:

• CLAUDE.md / AGENTS.md: An instruction file that gives the project persistent context; loaded automatically every session.
• .claude/skills/<name>/SKILL.md: Packets of procedural knowledge — loaded only when used, so they don't bloat context.
• Subagents: Helper agents that run in a separate context window, dividing up the work.

Per official documentation, the built-in Explore and Plan subagents skip CLAUDE.md files and the git status snapshot by default to keep speed up — meaning they're designed so that "exploration stays fast and cheap"; custom subagents can explicitly load CLAUDE.md if wanted.

In practice, combining these three building blocks looks like adding a short spec-discipline rule inside CLAUDE.md:

1# Working rule
2 
3For new feature requests, first produce a mini-spec in Plan Mode
4(what will be done, which files will change, what the risks are),
5get approval, then implement. The spec gets copied into the PR description.

This is a miniature counterpart to Spec Kit's spec.md file — layered on top of the existing CLAUDE.md mechanism, without installing a separate CLI.

Together, these three set up a "spec + plan + execute" arrangement, but unlike Spec Kit or Kiro, it doesn't impose a separate CLI install, a separate notation, or a separate file schema — it's repo-local, plain text, and editor-agnostic. Our Claude Code Plan Mode guide covers this planning flow in more depth, and our Claude Code Hooks guide covers the automation layer.

Trying the same feature across all three tools

Putting the command chains documented in each tool's official docs side by side on a single request makes the difference concrete.

Scenario: "Add an avatar upload feature to the user profile."

In the flow Spec Kit documents, the command chain runs like this:

1/speckit-specify "Add an avatar upload feature to the user profile"
2/speckit-plan
3/speckit-tasks
4/speckit-implement

Each command produces a file (spec.md, plan.md, tasks.md), and these stay in the repo as plain Markdown — you can review the spec change separately from the code change with git diff if you want.

In Kiro, the same request turns into requirements.md in EARS form, followed by design.md and a dependency-ordered tasks.md — all under .kiro/specs/, with approval gates. The real weight is on design.md: official docs define it as the place holding technical architecture, sequence diagrams, and implementation considerations, branched under six headings — Architecture, Data Flow, Interfaces, Data Models, Error Handling, and Unit Testing Strategy. So in Kiro, "design" isn't a one-paragraph statement of intent — it's a structured document covering components and their interactions; even a small request like avatar upload must fill in storage interface, error states, and test strategy. A secondary source notes these three files derive from a single prompt, with tasks ordered by dependency (codemyspec.com).

In Claude Code's built-in path, there's no official "spec command" — the discipline is on you: you either write a rule into CLAUDE.md like "new features are designed in plan mode first," or you define your own spec template with a SKILL.md. Less ceremony, more flexibility — but for an enterprise team, the guarantee that "every agent uses the same format" isn't as strong as with Spec Kit or Kiro.

Putting the files each approach produces side by side makes the difference clear:

Who should choose which

• Solo developer / indie: Spec Kit. Free, MIT-licensed, plugs into your existing agent (including Claude Code), doesn't require an AWS account.
• Small team using multiple agents (some Copilot, some Claude Code): Spec Kit again — 38 integrations and a "no lock-in" principle unify tool diversity within the team at the spec level.
• AWS-native enterprise team, or a team migrating off Amazon Q Developer: Kiro makes sense — EARS notation provides traceability in regulated sectors requiring audit/compliance (finance, healthcare), and in-IDE approval gates align with enterprise process.
• Anyone already using Claude Code who doesn't want to install another tool: Try the built-in path first (CLAUDE.md + skill + subagent); if it's not enough, layer Spec Kit on top of Claude Code — the two don't conflict, they complement each other.

A single axis underlies these four points: not "which tool wins," but where you want to stand between process depth and portability. Kiro picks depth — EARS, a six-heading design document, approval gates — but ties you to its own surfaces and credit system. Spec Kit picks portability: the same discipline travels with whichever agent you use, in exchange for setting everything up yourself. Claude Code's built-in path is a third balance: you define the depth yourself, making it both the most flexible option and the most fragile at team scale.

FAQ

Should I choose GitHub Spec Kit or AWS Kiro?

Spec Kit is MIT-licensed and works with 38 agents/editors (the official list counts Copilot, Gemini, Codex, Kilo Code, Zed, Claude, Forge, and Kiro) — a portable CLI scaffold whose specs stay in your repo as plain Markdown. Kiro, on the other hand, is AWS's integrated product that automates spec production across IDE, CLI, web, and mobile surfaces, but ties you to the AWS ecosystem and credit-based pricing. If multi-agent support and portability are your priority, go with Spec Kit; if you're in an AWS-native enterprise environment or migrating off Amazon Q Developer, Kiro makes more sense.

Which AI coding tools does Spec Kit work with?

Spec Kit is designed to be agent-agnostic; per its official site it supports a total of 38 agent/editor integrations and embraces a "no lock-in" principle. Those named on the homepage include Copilot, Gemini, Codex, Kilo Code, Zed, Claude, Forge, and — despite being a competitor — Kiro; the full list lives in the official integration catalog.

What is Kiro's EARS notation?

EARS (Easy Approach to Requirements Syntax) is the structured requirement format Kiro uses in its requirements.md files; its base pattern is "WHEN [condition/event] THE SYSTEM SHALL [expected behavior]." The goal is for both the developer and the AI agent to parse the same sentence the same way, without guessing.

How do you do spec-driven development inside Claude Code?

There are two paths: the first is installing Spec Kit with its Claude Code integration and using the /speckit-* command chain — a short spec gets written first, turned into a task plan, and Claude Code applies each task with approval between steps. The second is setting up a lighter, repo-local spec discipline with Claude Code's own CLAUDE.md + SKILL.md + subagent system.

What's the difference between Spec Kit's short path and full path?

The short path consists of five commands (/speckit-specify, /speckit-plan, /speckit-tasks, /speckit-implement, /speckit-converge) and is designed for fast iteration. The full path adds the /speckit-clarify, /speckit-checklist, and /speckit-analyze quality gates on top of these; it's recommended for features headed to production that multiple people will touch.

How does Kiro's pricing compare to Spec Kit's?

Spec Kit itself is free — the only cost comes from the subscription of whichever AI agent you connect it to (Claude Code, Copilot, etc.). Kiro, on the other hand, runs a separate credit system: 50 credits on the Free tier, a fixed $0.02 per credit on paid plans ($20–$200), and $0.04 on overage. In other words, choosing Spec Kit doesn't add an extra tool bill; choosing Kiro means a separate budget line for every person/team using the IDE.

If you want to weigh price and lock-in risk together, the safest path is to try the Free tier on a small pilot feature first, measure daily credit consumption, then pick a package based on team size. The community backlash Kiro's split credit model drew in August 2025 (see the "Adoption asymmetry" and "AWS Kiro" sections) is also a reminder of why it's worth tracking pricing changes.

Conclusion

Choose spec-driven development not by asking "which tool is best," but "what do I gain against which risk profile." Spec Kit sells portability and openness; Kiro sells structured traceability and AWS integration; Claude Code's built-in path offers maximum flexibility with minimum ceremony. The three aren't mutually exclusive — many teams run Claude Code as their daily driver while bringing in Spec Kit's quality gates for critical features.

If you want to go deeper, our Claude Code Multi-Agent Teams guide covers parallel agent coordination, our Claude Code MCP guide covers tool/plugin integration, our GitHub Copilot vs Claude Code vs Cursor comparison covers daily editor choice, and the Vibe Coding Security Checklist covers security auditing of AI-generated code. To see where spec discipline fits in the move from vibe coding to production, check out our Taking a Vibe-Coded MVP to Production article.

Sources

• GitHub Spec Kit API — stargazers/pushed_at — live star count (138,408) and last push date (2026-09-22).
• AWS Kiro API — stargazers/pushed_at — live star count (4,328), last push (2026-09-15), and license: null.
• Spec Kit Quickstart — official documentation — setup, /speckit-* command chain, short path/full path distinction.
• Spec Kit official homepage — 38 integrations, 157 community plugins, 33 presets, "no lock-in."
• Kiro Feature Specs — official documentation — EARS notation, Requirements-First/Design-First flows, Quick Spec.
• Kiro pricing — official documentation — Free/Pro/Pro+/Pro Max/Power credit packages and overage fees.
• Spec Kit vs Kiro comparison — architecture summary and August 2025 credit model discussion.
• Amazon Q Developer end-of-support announcement — AWS DevOps Blog — April 30, 2027 end of support, 12-month Kiro migration, and model changes.
• Kiro documentation index (llms.txt) — unified agent harness; IDE, CLI, web, and mobile surfaces.
• Star History — github/spec-kit — star growth trend (independent verification).
• Claude Code Sub-agents — official documentation — Explore/Plan subagents' behavior of skipping CLAUDE.md.
• Claude Code Memory — official documentation — CLAUDE.md/AGENTS.md persistent context mechanism.