# SpecScore vs Kiro

Canonical: https://specscore.md/vs/kiro/

[Spec-driven development](https://specscore.md/spec-driven-development/) (SDD) means writing down what the software should do before an AI agent writes the code. [Kiro](https://kiro.dev/), from Amazon Web Services (AWS), is an agentic development environment — an editor, a [command-line interface](https://specscore.md/cli/) (CLI), and a web app — that turns a prompt into Kiro specs: requirements, a design, and tasks. Those requirements use [EARS](https://kiro.dev/docs/specs/feature-specs/) (Easy Approach to Requirements Syntax), sentences shaped as “WHEN something happens, THE SYSTEM SHALL do something.” [SpecScore](https://specscore.md/) is an [open-source](https://github.com/specscore/specscore) format for the specification itself, plus a CLI that checks the files. [Continuous integration](https://specscore.md/validators/) (CI) — an automatic check on every proposed change — can reject a SpecScore spec that breaks the format.

## What they share.

- Both treat a written specification as the thing an agent should build from, not a chat transcript.
- Both keep that specification as Markdown in the project, so it can be reviewed like code.
- Both break work into requirements, a design, and tasks. Kiro generates those three files. SpecScore is a format a team can keep after the session ends.

## What Kiro does well.

Kiro’s own docs, read 30 October 2026, describe the product. The feature-spec page was marked updated on 4 August 2026.

### Requirements in a fixed sentence shape

Kiro specs put behavior in `requirements.md` using one EARS pattern: WHEN a condition holds, THE SYSTEM SHALL do a thing. The docs give the example of a form with invalid data, and the system showing a validation error next to the field. That shape is easier to test than a vague paragraph.

### A full path from prompt to tasks

A feature spec moves through requirements, design (`design.md`), and tasks (`tasks.md`). You can start from requirements or from a design. Quick Spec runs all three without an approval stop between them. Bugfix specs are a separate path. The docs also describe running independent tasks in parallel, in waves, from the dependency graph in `tasks.md`.

### Checks inside the product

Analyze Requirements, available in the IDE and the CLI, looks for inconsistencies, ambiguity, conflicting constraints, and gaps before design. Correctness — property-based tests drawn from those EARS lines — is listed for the IDE only, not the CLI, web, or mobile, on the specs capability table.

## Feature comparison.

Kiro is a product that drafts specs. SpecScore is the format a repository can check. The table compares those roles.

| Capability | Kiro | SpecScore |
| --- | --- | --- |
| Primary role | Agentic IDE, CLI, and web app that drafts specs and implements tasks | **Open spec format + CLI** |
| Spec files | `requirements.md` (or `bugfix.md`), `design.md`, `tasks.md` | **A spec/ tree** of Markdown + YAML |
| Requirements syntax | EARS pattern: WHEN … THE SYSTEM SHALL … | **Requirement ids** (`REQ: slug`) and [Given/When/Then](https://specscore.md/acceptance-criteria-specification) acceptance criteria |
| Checking the spec | Analyze Requirements in the IDE and CLI. Property-based tests in the IDE. Not described as a format linter for your own CI. | **specscore spec lint** in CI. `/score` is a separate, manual AI grade. |
| Where it runs | Kiro IDE, Kiro CLI, Kiro web. Some checks are IDE-only. | **Any repo** — one Go binary, no Kiro account |
| License | The [Kiro license](https://kiro.dev/license/) says the IDE and CLI are AWS Content under the AWS Customer Agreement. Kiro Crew is a separate [public repository](https://github.com/kirodotdev/KiroCrew). | [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE) format · [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE) CLI |
| Price | A free tier and paid plans. Figures move — see [Kiro pricing](https://kiro.dev/pricing/), read 30 October 2026. | **No fee** for the format or the CLI |

## What SpecScore adds.

### The format fails CI on its own

Kiro’s analysis runs inside Kiro. SpecScore’s check is a command. This repository’s [dogfood workflow](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) runs `specscore spec lint` on every pull request and on main. A broken spec fails the job the way a broken test would. The [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) skill grades wording with AI reviewers; that pass is manual, and the workflow above does not run it.

```
$ specscore spec lint

features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found
features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds
features/apply-discount/refunds:0 [error] readme-exists: README.md not found

3 violations found (3 errors)
```

### The spec is not tied to one IDE

Kiro specs are Markdown, so you can read them without the product. The workflow that creates and executes them is Kiro’s. A SpecScore tree is the same files for Claude Code, Cursor, Copilot, or no agent at all — the CLI does not call a model to lint.

### Requirements keep an id

Kiro’s docs describe traceability as following a requirement through implementation. They do not describe a stable id that survives a rewrite. SpecScore addresses a requirement as `REQ: slug` and an acceptance criterion by its own id.

### EARS and Given/When/Then answer different questions

EARS, as Kiro documents it, is one sentence of system behavior. SpecScore acceptance criteria are Given/When/Then scenarios tied to a requirement id. You can write an EARS line in prose and still keep the scenario in the SpecScore file the linter checks. The sentence patterns are in [EARS requirements syntax](https://specscore.md/articles/ears-requirements/).

## When to use which.

### Reach for Kiro when…

- You want an AWS agentic IDE that drafts requirements, design, and tasks from a prompt and then implements the tasks.
- You want EARS sentences and, in the IDE, property-based tests generated from them.
- Your team is already standardizing on Kiro’s editor, CLI, or web app.

### Use SpecScore when…

- The spec has to stay valid in CI after the agent session ends, in a repository that does not require Kiro.
- You need requirement ids, lifecycle status, and a deterministic lint result.
- You want the format [open-source](https://github.com/specscore/specscore) and the checker to be a single binary.

## Kiro can draft. SpecScore can gate.

Nothing here replaces Kiro’s editor. If Kiro is where the team prompts, let it draft. If the specification has to survive as a reviewed file, write that contract in SpecScore and let `specscore spec lint` fail the pull request when the structure breaks. The two files can sit in the same repository.

Pick Kiro for the session. Pick SpecScore for the artifact a CI job can refuse.

## Sources.

The public pages below were read on 30 October 2026. Prices, plan names, and release lines change.

- [Kiro docs — Specs](https://kiro.dev/docs/specs/)
- [Kiro docs — Feature specs and EARS](https://kiro.dev/docs/specs/feature-specs/)
- [Kiro — About](https://kiro.dev/about/)
- [Kiro — License](https://kiro.dev/license/)
- [Kiro — Pricing](https://kiro.dev/pricing/)
- [specscore/specscore — dogfood CI workflow](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specstudio-skills — /score skill](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md)
- [specscore/specscore — CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)
- [specscore/specscore-cli — Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)