The outcome
Create versioned guidance and triggers that improve consistency while preserving clear ownership and approval.
Kiro is a agentic integrated development environment from AWS. Turning feature ideas into requirements, design, tasks, and implementation while preserving repository guidance and explicit review of agent changes. This guide narrows that broad capability into one repeatable outcome, with checkpoints that keep the source material and your judgment in the loop.
Before you begin
Set the boundary before the tool starts.
Choose one real task, identify who will use the result, and decide what evidence or test will make the result acceptable. Gather only the source material needed for that task. If the work contains confidential, personal, regulated, or client-owned information, confirm that the platform and account are approved before sharing it.
AI should make the work easier to inspect. If the workflow removes the source, the owner, or the review step, redesign the workflow.
Step by step
A workflow you can repeat.
- 01
Collect stable architecture rules, commands, conventions, prohibited changes, and review requirements, separating them from temporary task details.
- 02
Write concise scoped steering files, link canonical repository documentation, and exclude secrets, private credentials, and unnecessary source content.
- 03
Add only narrowly useful hooks with explicit events, actions, timeouts, failure behavior, owners, and no production side effects.
- 04
Test steering and hooks on a disposable branch with normal, malformed, adversarial, duplicate, failing-command, and unexpected-file cases.
- 05
Review trusted-command patterns and protected paths, version all shared configuration, and remove stale guidance whenever tooling or architecture changes.
Working standard
What good use looks like.
- Keep steering stable and scoped.
- Make hook side effects explicit.
- Avoid broad trusted-command wildcards.
Supervised and Autopilot modes have similar underlying file and command access; supervised mode adds a review-and-revert workflow rather than a stronger sandbox. Use repository-scoped authentication, temporary AWS credentials, carefully bounded trusted-command prefixes, protected paths, reviewed extensions and MCP servers, human-approved specs, checkpoints, and independent tests. Never use a universal command trust pattern on untrusted content.
Official references
Check the current product documentation.
Features, plan limits, availability, and data controls change. These official pages are the starting points used for this collection.