What Is Kiro? Amazon’s Spec-Driven IDE Explained

Kiro is an AI coding environment from Amazon Web Services that plans before it builds. Give it a feature request and, instead of editing files straight away, it writes a spec: a requirements file, a design file and a task list, each of which you can read, change and approve. Then its agent works through the tasks. Around that sit steering files that hold your project’s standing rules, hooks that run on events such as a file save, and MCP for connecting outside tools. Kiro started as a desktop IDE and now runs the same agent in a terminal CLI, a web app and more. If you want an agent that writes the plan down before it touches the code, that is the idea Kiro is built on.

Who makes it

Kiro comes from AWS. The AWS documentation overview for Kiro↗ (opens in a new tab) describes it as an agentic coding service that works alongside you to turn prompts into detailed specs, then into working code, docs and tests, and says it runs on Amazon Bedrock. You do not sign in with an AWS console account by default: Kiro’s installation guide offers Google, GitHub, AWS Builder ID or your organisation’s identity provider.

Where it runs

Kiro’s documentation describes one agent behind every surface, reading the same .kiro/ folder in your project, so a steering file or hook you write once applies wherever you work:

• IDE: the desktop editor, for macOS, Windows and Linux, with chat, specs, hooks and the usual editor features. You can import your VS Code settings and extensions when you first set it up.
• CLI: a terminal agent with a headless mode for CI. It installs with a script and starts with kiro-cli in your project folder.
• Web: a browser agent for planning across repositories and automating pull requests.
• Mobile: an iOS app in preview for following tasks and reviewing pull requests away from your desk.
• Crew: a personal agent for scheduled and autonomous tasks.

Specs: requirements, design, tasks

Specs are the part that makes Kiro Kiro. Its specs documentation↗ (opens in a new tab) calls them structured artifacts that formalise the development process, and a spec has three files. requirements.md holds user stories and acceptance criteria, or for a bug a bugfix.md with the analysis; design.md holds the architecture, sequence diagrams and implementation notes; tasks.md holds the implementation plan as discrete tasks. Each spec gets its own folder under .kiro/specs/.

• Feature specs start either requirements first, from the behaviour you want, or design first, from an architecture you have already settled.
• Bugfix specs record what happens now, what should happen and what must not change, so the fix does not break something else.
• Quick Spec writes all three files in one pass, without the approval gates, for work you already understand.
• Requirements use EARS notation: “WHEN [condition or event] THE SYSTEM SHALL [expected behaviour]”, which turns each one into something you can test.

When you run all the tasks in a spec, Kiro works out which depend on which and runs independent tasks at the same time, in waves. The method behind this, and how to do it without Kiro, is in spec-driven development.

Steering files: the standing rules

A spec is per feature; steering is for everything. Kiro’s steering documentation↗ (opens in a new tab) describes Markdown files that give the agent persistent knowledge of your project, kept in .kiro/steering/ for the workspace, ~/.kiro/steering/ for all your projects, or in the web settings. Kiro can generate three foundation files for a new project: product.md for what the product is for, tech.md for the stack, and structure.md for how files are organised and named.

Frontmatter decides when a file is loaded. always is the default; fileMatch loads it only when matching files are in play; manual loads it when you mention it with # in chat; and auto loads it when your request matches its description. Kiro also reads AGENTS.md, always included, so rules you already share with other agents apply without a copy.

---
inclusion: fileMatch
fileMatchPattern: ["src/api/**/*.ts"]
---
# API conventions
- Every endpoint validates its input with the shared schema module.
- Errors return { error, message }; never a bare string.
- New endpoints get an integration test in tests/api/.

Hooks: checks that run on events

Kiro’s hooks↗ (opens in a new tab) run a shell command or add a prompt to the conversation when something happens: a prompt is submitted, the agent stops, a tool is about to run or has run, or, in the IDE, a file is created, saved or deleted, or a spec task starts or finishes. Some can block: a Pre Tool Use or Pre Task Execution hook can stop the action before it happens. File triggers fire only on changes the agent makes, not on your own saves. Hooks are JSON files in .kiro/hooks/, and you can also describe one in chat and let Kiro write it.

{
  "version": "v1",
  "hooks": [
    {
      "name": "Lint on save",
      "trigger": "PostFileSave",
      "matcher": "\\.(ts|tsx)$",
      "action": { "type": "command", "command": "npx eslint --fix" }
    }
  ]
}

How Kiro’s hooks line up against Claude Code’s, event by event, is in Kiro vs Claude Code; a worked example of hooks that update a board is in Claude Code hooks: update a board automatically.

MCP

Kiro is an MCP client in the IDE, the CLI and the web. Servers go in .kiro/settings/mcp.json for the workspace or ~/.kiro/settings/mcp.json for you, and the workspace file wins a conflict. A remote server needs a url and optional headers; OAuth sign-in happens in the browser. autoApprove lists tools that may run without asking, and disabledTools hides tools you never want called. If MCP is new to you, what MCP is explains the idea.

Autopilot and Supervised

The IDE has two autonomy settings. Kiro’s Autopilot page↗ (opens in a new tab) says Autopilot, the default, completes tasks end to end, and you can view all changes, revert them or interrupt it. Supervised stops after each turn that edits files and lets you accept or reject changes hunk by hunk or file by file. Switch with the toggle in the chat or under Settings, Agent, Agent Autonomy. Start in Supervised on a codebase you care about; move to Autopilot when you know how it behaves.

Getting started

1. Download the IDE from kiro.dev, sign in with Google, GitHub, AWS Builder ID or your organisation, and import your VS Code settings if you want them.
2. Open a project and have Kiro generate the three foundation steering files. Read them; correct anything it guessed wrong.
3. Pick a small feature and start a spec from the chat. Approve the requirements, then the design, then the tasks, editing each before you move on.
4. Run one task at a time in Supervised mode, and check each result against its requirement.
5. Add one hook, such as a linter on save, once you know which check you keep running by hand.

curl -fsSL https://cli.kiro.dev/install | bash
cd my-project
kiro-cli

The Kiro CLI documentation↗ (opens in a new tab) covers the rest: custom agents, skills, subagents that run in parallel, and a headless mode that takes an API key for CI pipelines.

Who it suits

• Teams that want requirements and a design reviewed before any code is written, every time, without building that process themselves.
• Work where the person who asks for a feature is not the person who reviews the code: a spec gives both something concrete to point at.
• Organisations that sign in through their own identity provider and want the agent’s rules in files the whole team shares.
• Less so: one-line fixes and throwaway experiments. Quick Spec is lighter than the full approval cycle, and for tiny jobs even that is ceremony.

Where the tasks go after the spec

tasks.md is the right list for the agent at work, and an awkward one for anyone who is not in the repository: the person who decides what is built next, or checks what came out. A shared board fixes that. Connect Kiro to fenbs by adding https://fenbs.ai/api/mcp as a remote server in .kiro/settings/mcp.json and signing in through the browser. Then each outcome someone would check becomes a fenbs task, with the requirement in its Problem box and the approach in its Plan box, moving through To Do, Next Up, In Progress and Completed, and every change is recorded in History under the assistant’s name, on your behalf.