> ## 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.

# Kiro Specs Framework Profile

> A source-backed profile of Kiro Specs: requirements-first, design-first, and quick-plan workflows with requirements, design, and task artifacts.

Kiro Specs is an IDE and web workflow that produces three primary artifacts: requirements or bug analysis, technical design, and tasks. Teams can begin with requirements, begin with the design, or use a quick plan that creates the same artifact set without gates between phases.

**Source stamp:** [official Kiro Specs documentation](https://kiro.dev/docs/specs/), captured July 18, 2026. Kiro's published content terms do not provide an open template license, so this page paraphrases and links rather than copying templates.

## Artifact tree

```text theme={null}
.kiro/specs/feature-name/
  requirements.md   # or bugfix.md
  design.md
  tasks.md
```

The official [requirements-first guide](https://kiro.dev/docs/specs/feature-specs/requirements-first/) describes user stories, acceptance criteria, EARS-style system behavior, functional requirements, and edge cases. Design covers architecture, components, sequences, data models, interfaces, error handling, and testing. The task file provides discrete implementation work.

## Workflow variants

| Mode               | Starting point                        | Review shape                                             |
| ------------------ | ------------------------------------- | -------------------------------------------------------- |
| Requirements-first | User behavior and acceptance criteria | Requirements lead into design and tasks                  |
| Design-first       | Technical direction                   | Design leads, then requirements and tasks are reconciled |
| Quick plan         | Clarifying questions and one pass     | Produces the three artifacts without phase gates         |

Kiro's [steering](https://kiro.dev/docs/steering/) supplies persistent project guidance outside the feature directory. In chat, the spec artifacts can be brought back into context for implementation or validation.

## Review and handoff conventions

The artifact set gives reviewers separate places to challenge expected behavior, technical design, and execution tasks. On the web, users can refine artifacts before running all or selected tasks and can download the Markdown. In the IDE, the files remain in the repository's `.kiro/specs/` directory.

## Inspect a source-faithful example

Inspect the [manual, source-faithful Kiro three-file example for reliable webhook delivery](https://github.com/plannotator/spec-planning-frameworks/tree/main/examples/kiro-specs/manual). It was not generated by Kiro. The comparison could not run the vendor workflow without Kiro authentication, so the original example follows the public artifact model and labels that limit in every file.

## Choose Kiro Specs when

* the team already works in Kiro and wants integrated artifact editing and task execution;
* three consistent files are enough for the feature;
* requirements-first and design-first entry points are both useful; or
* a quick-plan mode should remove intermediate gates.

Use [GitHub Spec Kit vs Kiro Specs](/compare/github-spec-kit-vs-kiro-specs) for the direct choice. Plannotator does not redistribute Kiro templates; use the official product to create them.

*Reviewed July 19, 2026. Researched and maintained by the Plannotator documentation team. Kiro is named for identification; Plannotator is not affiliated with or endorsed by AWS.*