Skip to main content

Buyer guide

Kiro Workflow Playbook

Steering, spec sizing, permissions, and review practice for engineers moving multi-file work to Kiro's IDE, CLI, or cloud sessions.

Reading time
3 min read
Sources
13 cited
In this piece
Kiro+10 Mixed

Before engineers hand multi-file work to Kiro, commit steering files to the repository, reserve specs for multi-file and design work, and set permissions. Check each closed task against its spec and tests, using defaults from Kiro's documentation. Public accounts from an engineering manager, a Thoughtworks distinguished engineer and individual engineers show where those defaults break.

When you need this

  • Engineers are moving from chat prompts to feature and bugfix specs.
  • Results vary by engineer because conventions live in people's heads and outside steering files.
  • Specs are growing past what reviewers read, or are written for one-line fixes.
  • Agent changes reach pull requests before anyone has checked them against the spec and the tests.

Evaluation criteria

  1. Steering in the repository

    Where do the agent's standing instructions live, and who maintains them?

    Look forCommit workspace steering under .kiro/steering. Kiro includes product.md, tech.md, and structure.md in every interaction and also reads AGENTS.md. Push team steering to ~/.kiro/steering through MDM. AWS teams share AGENTS.md files and team-specific skills. One daily CLI user puts account names and conventions in steering so new sessions retain them.

  2. Spec size

    Which changes get a spec, and how long can one be?

    Look forUse feature specs for multi-file work or design decisions. Use Bugfix Specs for regressions, recording current and expected behavior plus what must stay unchanged. Use plain chat for smaller changes. When Thoughtworks' Birgitta Böckeler asked Kiro to fix a small bug, the requirements came back as 4 user stories with 16 acceptance criteria.

  3. Permissions

    What can the agent run, read, and fetch without asking?

    Look forSet capability rules for file access, shell commands, web tools, and MCP. Each accepts allow, ask, or deny, and deny wins. The IDE defaults to workspace reads and read-only git commands without approval. It asks about everything else. Keep destructive commands and writes outside the workspace on ask or deny.

  4. Task execution

    How much does the agent do before a person looks?

    Look forRun tasks individually or together, with independent tasks in parallel waves. Commit before long runs. Checkpoints restore files and context but miss changes from shell commands and MCP tools. An engineering manager tested the agent alone and corrected mistakes before running parallel CLI subagents across 30+ repositories.

  5. Checking the result

    What runs before a change leaves the engineer's machine?

    Look forRun the project's tests. Where Kiro supports it, generate property-based tests from the spec and add hooks that lint or type-check each edit. Check each closed task against its spec. One early tester had to stop Kiro from working around unresolved environment problems when it should have fixed them.

  6. Session length

    When should engineers start a fresh session?

    Look forKeep each session to one task. A daily CLI user reports repeated file reads and ignored early instructions after an hour or two. Compact or restart at that point. Carry context into the new session through specs and steering.

Questions to ask vendors

  1. Which steering files do every member's sessions load, and who reviews changes to them?
  2. What is our rule for when a change gets a feature spec, a Bugfix Spec, or no spec?
  3. Which shell, MCP, and web actions do we allow without approval, and which do we deny?
  4. Which hooks run after agent edits, and do they block or only report?
  5. How do reviewers check a merged change against its spec?

Red flags

  • Specs over several hundred lines that no reviewer reads in full.
  • Steering kept on one engineer's machine and absent from the repository.
  • Tasks closed by the agent with tests skipped or failing.
  • Long-running agent work with no commit to return to, since checkpoints miss shell changes.

Products in this piece

Sources

Official documentation
8
Public source
5
  1. Kiro docs: SpecsOfficial documentationkiro.dev
  2. Kiro docs: Bugfix specsOfficial documentationkiro.dev
  3. Kiro docs: SteeringOfficial documentationkiro.dev
  4. Kiro docs: HooksOfficial documentationkiro.dev
  5. Kiro docs: PermissionsOfficial documentationkiro.dev
  6. Kiro docs: What's new in IDE 1.0Official documentationkiro.dev
  7. Kiro docs: Checkpoints and rewindOfficial documentationkiro.dev
  8. Kiro docs: SubagentsOfficial documentationkiro.dev
  9. Birgitta Böckeler, Thoughtworks, on martinfowler.com: Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl (Oct 15, 2025)Public sourcemartinfowler.com
  10. Yehuda Cohen: Developing with Kiro: Amazon's New Agentic IDE (Jul 14, 2025)Public sourceyehudacohen.substack.com
  11. Hacker News comment by sparrc, an AWS engineer, on Kiro use inside AWS (Jun 9, 2026)Public sourcenews.ycombinator.com
  12. Sarvar Nadaf: Kiro CLI Gets Worse After an Hour. Here's How I Fixed It. (Jul 16, 2026)Public sourcedev.to
  13. Davide de Paolis: Kiro showcase: Automating Changes Across Several Repos with Spec-Driven Development and Custom Sub-Agents (Apr 7, 2026)Public sourcedev.to

Keep reading

  1. Buyer guideRolling Out Kiro to a TeamKiro profiles, sign-in through IAM Identity Center, Okta, or Entra ID, tier assignment, overage caps, and the shared steering a team rollout needs.
  2. Buyer guideKiro Data Handling & Governance ChecklistWhat Kiro stores and trains on by sign-in type, where inference runs, and which admin controls cover models, MCP, web tools, and cloud sessions.
  3. Buyer guideMoving from Amazon Q Developer to KiroWhat changes for Q Developer CLI and IDE plugin users, how Q Developer Pro seats map to Kiro tiers, and which transformation jobs to finish. Both plugins and paid subscriptions end on April 30, 2027; settle the move before then.
Read the research