> ## Documentation Index
> Fetch the complete documentation index at: https://docs.plannotator.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# GitHub Spec Kit vs Kiro Specs

> Compare GitHub Spec Kit and Kiro Specs by artifact set, workflow modes, requirement style, task structure, tool coupling, persistence, and reuse rights.

Choose GitHub Spec Kit when you want an open, tool-portable feature directory with a constitution and extended technical artifacts. Choose Kiro Specs when you want an integrated requirements, design, and tasks workflow inside Kiro, including requirements-first, design-first, and quick-plan modes.

**Sources:** [`github/spec-kit` at `57cc518d`](https://github.com/github/spec-kit/tree/57cc518d63d6f10da3dd93df1ebcadda87c59374) and the [official Kiro Specs documentation](https://kiro.dev/docs/specs/), captured July 18, 2026. Spec Kit is MIT. Kiro does not publish an open template license in the reviewed documentation, so this site paraphrases Kiro and links to the official source.

## Artifact and workflow comparison

| Dimension             | GitHub Spec Kit                                                                      | Kiro Specs                                                                                   |
| --------------------- | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| Primary artifact set  | Constitution, spec, plan, research, data model, contracts, quickstart, tasks         | Requirements or bug analysis, design, tasks                                                  |
| Default sequence      | Specify, Plan, Tasks, Implement                                                      | Requirements-first, design-first, or quick plan                                              |
| Requirement structure | Independently testable user stories, scenarios, requirement IDs, measurable outcomes | User stories, acceptance criteria, EARS-style behaviors, functional requirements, edge cases |
| Planning constraints  | Constitution checks and technical context                                            | Kiro steering and the selected spec workflow                                                 |
| Task structure        | Stable task IDs, parallel markers, user-story labels, exact paths                    | Discrete tasks managed in the Kiro spec interface                                            |
| Tool coupling         | Open repository toolkit with support for many coding agents                          | Kiro IDE and web product workflow                                                            |
| Persistence           | Explicit guidance for living or historical spec strategies                           | Files live under `.kiro/specs/`; the product can update them in place                        |

## Choose GitHub Spec Kit when

* a repository-owned feature directory should work across supported agents;
* a project constitution should constrain every feature plan;
* research, data model, contracts, and quickstart deserve separate artifacts; or
* stable requirement and task IDs help trace implementation.

The official [Spec Kit documentation](https://github.github.com/spec-kit/) explains the core workflow, and the project's templates make the exact structure inspectable.

## Choose Kiro Specs when

* Kiro is already the team's planning and implementation environment;
* the same three-file artifact set is enough;
* requirements-first and design-first entry points are both useful; or
* quick plan should create the artifacts without intermediate gates.

The [requirements-first guide](https://kiro.dev/docs/specs/feature-specs/requirements-first/) and [quick-plan guide](https://kiro.dev/docs/specs/quick-plan/) document those modes.

## Rights matter for a template gallery

Spec Kit's MIT license permits reuse with its notice. Kiro's public content terms do not provide the same open-template permission. That difference does not judge product quality, but it changes what a documentation site can safely redistribute. Plannotator links to Kiro's official artifacts instead of copying them.

## Inspect both same-case outputs

* [Complete generated Spec Kit artifact tree](https://github.com/plannotator/spec-planning-frameworks/tree/main/examples/github-spec-kit/raw): the planning flow produced the constitution, specification, plan, supporting technical artifacts, and tasks.
* [Manual, source-faithful Kiro example](https://github.com/plannotator/spec-planning-frameworks/tree/main/examples/kiro-specs/manual): the three files follow Kiro's public artifact model but were not generated by Kiro because the vendor workflow required unavailable authentication.

Read the full [GitHub Spec Kit](/frameworks/github-spec-kit) and [Kiro Specs](/frameworks/kiro-specs) profiles, or start with the original [technical specification template](/templates/technical-specification).

*Reviewed July 19, 2026. Researched and maintained by the Plannotator documentation team. GitHub and Kiro are not affiliated with or endorsed by Plannotator.*