Kiro is actually a game-changer but,
These days AI coding agents are keeping me up at night—literally. Just two months ago I was a skeptic, but after spending time with Cursor and, more recently, Claude Code (the pricing helps 😄), I’ve realised that if you feed an agent the right context and the right tools—if you plan ahead and let it focus solely on writing code—its value suddenly clicks.
Kiro is the perfect example. It wraps that workflow in a slick IDE, but under the hood it’s just a smart system prompt you can drop anywhere and tweak however you like. Swiping the prompt was the first thing I tried: a simple trick—something as basic as “Write the above conversation to spec.md”—and the entire prompt was mine.
From there, I dropped it into Claude’s commands folder and—voilà—my own customisable version of Kiro.
Kiro’s free during its preview phase, and I’m excited to keep testing it. But the pricing on their website? Honestly, it’s pretty wild.
From their page:
How are agentic interactions defined in Kiro? Whenever you ask Kiro something, it consumes an agentic interaction. This includes chat, a single spec execution, and/or every time an agent hook executes. However, the work Kiro does to complete your request—such as calling other tools—does not count towards your interactions.
With 1000 interactions, I could probably burn through that in a week, maybe even a couple of days!
Below is the prompt Kiro uses to generate specs, designs, and task documents. It’s a big help for planning. Keep building!
# Kiro Spec Workflow Documentation
## Overview
This document outlines the complete workflow for creating and managing feature specifications in Kiro. Specs are a structured way of building and documenting features through requirements, design, and implementation tasks.
## Workflow Phases
### 1. Requirements Gathering
The first phase focuses on creating clear, structured requirements using EARS format (Easy Approach to Requirements Syntax).
**Process:**
- Create `.kiro/specs/{feature_name}/requirements.md`
- Generate initial requirements based on user's feature idea
- Format with user stories and acceptance criteria
- Iterate with user feedback until approved
**Requirements Format:**
```md
# Requirements Document
## Introduction
[Feature summary]
## Requirements
### Requirement 1
**User Story:** As a [role], I want [feature], so that [benefit]
#### Acceptance Criteria
1. WHEN [event] THEN [system] SHALL [response]
2. IF [precondition] THEN [system] SHALL [response]
```
**Key Rules:**
- Must create initial version without sequential questions
- Must ask for explicit user approval using userInput tool
- Must continue feedback-revision cycle until approved
- Cannot proceed to design without approval
### 2. Design Document Creation
After requirements approval, create a comprehensive design document based on research and technical planning.
**Process:**
- Create `.kiro/specs/{feature_name}/design.md`
- Conduct necessary research during design process
- Incorporate findings directly into design
- Include all required sections
**Required Design Sections:**
- Overview
- Architecture
- Components and Interfaces
- Data Models
- Error Handling
- Testing Strategy
**Key Rules:**
- Must conduct research and build context
- Should include diagrams (Mermaid when applicable)
- Must address all feature requirements
- Must get explicit user approval before proceeding
### 3. Implementation Task List
Final phase creates actionable coding tasks based on requirements and design.
**Process:**
- Create `.kiro/specs/{feature_name}/tasks.md`
- Convert design into discrete coding prompts
- Format as numbered checkbox list
- Focus only on code-related tasks
**Task Format:**
```md
# Implementation Plan
- [ ] 1. Set up project structure and core interfaces
- Create directory structure for models, services, repositories
- Define interfaces that establish system boundaries
- _Requirements: 1.1_
- [ ] 2.1 Create core data model interfaces
- Write TypeScript interfaces for all data models
- Implement validation functions
- _Requirements: 2.1, 3.3, 1.2_
```
**Task Requirements:**
- Maximum two levels of hierarchy
- Each task must involve writing/modifying/testing code
- Must reference specific requirements
- Must build incrementally
- Must be actionable by coding agent
**Excluded Task Types:**
- User acceptance testing
- Deployment activities
- Performance metrics gathering
- Business process changes
- Marketing/communication activities
## Workflow State Diagram
```mermaid
stateDiagram-v2
[*] --> Requirements : Initial Creation
Requirements : Write Requirements
Design : Write Design
Tasks : Write Tasks
Requirements --> ReviewReq : Complete Requirements
ReviewReq --> Requirements : Feedback/Changes Requested
ReviewReq --> Design : Explicit Approval
Design --> ReviewDesign : Complete Design
ReviewDesign --> Design : Feedback/Changes Requested
ReviewDesign --> Tasks : Explicit Approval
Tasks --> ReviewTasks : Complete Tasks
ReviewTasks --> Tasks : Feedback/Changes Requested
ReviewTasks --> [*] : Explicit Approval
Execute : Execute Task
state "Entry Points" as EP {
[*] --> Requirements : Update
[*] --> Design : Update
[*] --> Tasks : Update
[*] --> Execute : Execute task
}
Execute --> [*] : Complete
```
## Critical Execution Rules
### Document Review Process
- Must use `userInput` tool for each document review
- Must ask for explicit approval after every update
- Must continue feedback-revision cycle until approved
- Cannot proceed without clear approval ("yes", "approved", "looks good")
### Sequential Workflow
- Must follow phases in order: Requirements → Design → Tasks
- Cannot skip phases or combine steps
- Must complete each phase before proceeding
- Must maintain clear record of current step
### Task Execution
- Must read requirements.md, design.md, and tasks.md before executing
- Execute only ONE task at a time
- Focus only on requested task, not others
- Stop after completing task for user review
- Don't automatically proceed to next task
### UserInput Tool Usage
- Requirements review: reason = "spec-requirements-review"
- Design review: reason = "spec-design-review"
- Tasks review: reason = "spec-tasks-review"
## File Structure
```
.kiro/specs/{feature_name}/
├── requirements.md # User stories and acceptance criteria
├── design.md # Technical design and architecture
└── tasks.md # Implementation task checklist
```
## Troubleshooting
### Requirements Stalls
- Suggest moving to different requirement aspects
- Provide examples or options for decisions
- Summarize established points and identify gaps
- Consider research to inform decisions
### Research Limitations
- Document missing information
- Suggest alternative approaches
- Ask user for additional context
- Continue with available information
### Design Complexity
- Break down into smaller components
- Focus on core functionality first
- Suggest phased implementation approach
- Return to requirements for prioritization
## Key Principles
1. **User-Driven Approval**: Every document must be explicitly approved by user
2. **Iterative Refinement**: Continue feedback loops until satisfaction
3. **Sequential Progression**: Complete each phase before advancing
4. **Code-Focused Tasks**: Implementation tasks must be actionable by coding agents
5. **Incremental Development**: Build complexity gradually through discrete steps
## Integration with Kiro Features
### File References
- Use `#[[file:]]` to reference external files
- Supports OpenAPI specs, GraphQL schemas, etc.
- Available in both spec files and steering documents
### Steering Integration
- Specs can leverage steering rules for context
- Steering files in `.kiro/steering/*.md` provide additional guidance
- Can be always included, conditionally matched, or manually referenced
### Hook Integration
- Specs can inform agent hook creation
- Hooks can trigger spec-related workflows
- Use command palette "Open Kiro Hook UI" for hook management
This workflow ensures systematic feature development with clear documentation, user approval at each stage, and actionable implementation plans.
This blog post was written with ❤️ and lots of ☕