Kiro Spec Writing Guide
Master Kiro's spec-driven development approach with EARS format requirements,
structured design documents, and actionable task lists. This guide covers everything
from basic syntax to advanced patterns for production-ready specifications.
What Are Kiro Specs?
Kiro specs are structured markdown documents that formalize your feature development process. Unlike traditional coding where you jump straight to implementation, Kiro enforces a three-phase approach:
- Requirements - What the system should do (EARS format)
- Design - How the system will work (architecture & interfaces)
- Tasks - Step-by-step implementation plan
EARS Format Requirements
EARS (Easy Approach to Requirements Syntax) is the foundation of Kiro specs. Each requirement follows this template:
WHEN [condition] THE SYSTEM SHALL [expected behavior]
Basic EARS Examples
User Authentication Feature
# Requirements ## User Registration WHEN a user submits valid registration data THE SYSTEM SHALL create a new user account WHEN a user submits an email that already exists THE SYSTEM SHALL display "Email already registered" error WHEN a user submits invalid email format THE SYSTEM SHALL display email validation error ## User Login WHEN a user enters correct credentials THE SYSTEM SHALL authenticate and redirect to dashboard WHEN a user enters incorrect password THE SYSTEM SHALL display "Invalid credentials" error WHEN a user fails login 3 times THE SYSTEM SHALL temporarily lock the account
Each EARS statement should be testable and specific. Avoid vague terms like "user-friendly" or "fast" - instead specify exact behaviors and error conditions.
Advanced EARS Patterns
E-commerce Cart System
# Shopping Cart Requirements ## Adding Items WHEN a user clicks "Add to Cart" on an available product THE SYSTEM SHALL add the item to their cart WHEN a user adds an item that exceeds stock quantity THE SYSTEM SHALL limit quantity to available stock WHEN a user adds the same item multiple times THE SYSTEM SHALL increment the quantity ## Cart Persistence WHEN a logged-in user adds items to cart THE SYSTEM SHALL persist cart across sessions WHEN a guest user adds items to cart THE SYSTEM SHALL store cart in browser session WHEN a guest user logs in with existing cart THE SYSTEM SHALL merge guest cart with user cart ## Checkout Process WHEN a user proceeds to checkout with valid items THE SYSTEM SHALL display order summary WHEN a user attempts checkout with out-of-stock items THE SYSTEM SHALL remove unavailable items and notify user WHEN payment processing fails THE SYSTEM SHALL preserve cart contents and display error message
Design Documents
After requirements are defined, Kiro generates a technical design document that includes:
- System architecture diagrams
- Data models and schemas
- API endpoint specifications
- Component hierarchies
- Integration points
Sample Design Document Structure
# Design Document: User Authentication ## Architecture Overview ``` Frontend (React) → API Gateway → Auth Service → Database ↓ JWT Token Service ``` ## Data Models ### User Schema ```typescript interface User { id: string; email: string; passwordHash: string; createdAt: Date; lastLoginAt?: Date; isLocked: boolean; failedLoginAttempts: number; } ``` ### Session Schema ```typescript interface Session { id: string; userId: string; token: string; expiresAt: Date; createdAt: Date; } ``` ## API Endpoints ### POST /auth/register - Input: { email, password } - Output: { user, token } | { error } - Validation: Email format, password strength ### POST /auth/login - Input: { email, password } - Output: { user, token } | { error } - Rate limiting: 5 attempts per 15 minutes ## Security Considerations - Passwords hashed with bcrypt (12 rounds) - JWT tokens expire after 24 hours - Account lockout after 3 failed attempts - HTTPS required for all auth endpoints
Task Lists
The final phase breaks down implementation into specific, actionable tasks. Kiro automatically generates these based on your requirements and design:
Generated Task List
# Implementation Tasks ## Backend Tasks - [ ] Create User model with validation - [ ] Implement password hashing utility - [ ] Create user registration endpoint - [ ] Add email uniqueness validation - [ ] Implement login endpoint with rate limiting - [ ] Create JWT token generation/validation - [ ] Add account lockout mechanism - [ ] Write unit tests for auth service ## Frontend Tasks - [ ] Create registration form component - [ ] Add form validation (email, password strength) - [ ] Implement login form component - [ ] Add error message display - [ ] Create protected route wrapper - [ ] Implement logout functionality - [ ] Add loading states for auth actions - [ ] Write component tests ## Integration Tasks - [ ] Set up API client for auth endpoints - [ ] Implement token storage (localStorage/cookies) - [ ] Add automatic token refresh - [ ] Create auth context/state management - [ ] Test complete auth flow - [ ] Add error boundary for auth failures ## Documentation Tasks - [ ] Update API documentation - [ ] Create user guide for auth features - [ ] Document security considerations - [ ] Add troubleshooting guide
Best Practices
Writing Effective Requirements
- Be Specific: "Display error message" → "Display 'Invalid email format' error below email field"
- Cover Edge Cases: Consider empty inputs, network failures, concurrent users
- Include Performance: "Login shall complete within 2 seconds under normal load"
- Define Success Criteria: What does "successful login" actually mean?
Design Document Tips
- Use Diagrams: Mermaid diagrams help visualize system flow
- Define Interfaces: Specify exact API contracts and data shapes
- Consider Scale: How will this work with 1000 users? 100,000?
- Plan for Failure: What happens when external services are down?
Task Organization
- Logical Ordering: Backend models before API endpoints
- Testable Chunks: Each task should be verifiable
- Include Quality Tasks: Testing, documentation, security reviews
- Estimate Complexity: Mark tasks as S/M/L for planning
Start with simple features to get comfortable with the spec format. A basic CRUD operation is perfect for learning the EARS syntax and task breakdown patterns.
Common Spec Patterns
API Feature Spec
# Feature: Product Search API ## Requirements WHEN a user searches with valid query THE SYSTEM SHALL return matching products WHEN a user searches with empty query THE SYSTEM SHALL return all products WHEN a user applies price filter THE SYSTEM SHALL return products within price range WHEN no products match criteria THE SYSTEM SHALL return empty results with appropriate message ## Design - GET /api/products/search?q={query}&minPrice={min}&maxPrice={max} - Elasticsearch backend for full-text search - Redis caching for popular queries - Pagination with limit/offset ## Tasks - [ ] Set up Elasticsearch index for products - [ ] Implement search service with filters - [ ] Add caching layer - [ ] Create API endpoint - [ ] Write integration tests
UI Component Spec
# Feature: Product Card Component ## Requirements WHEN product data is provided THE SYSTEM SHALL display product image, name, and price WHEN product is on sale THE SYSTEM SHALL show original and sale price WHEN user hovers over card THE SYSTEM SHALL show quick action buttons WHEN product is out of stock THE SYSTEM SHALL display "Out of Stock" overlay ## Design - React component with TypeScript props - Responsive design (mobile-first) - Accessibility: proper ARIA labels, keyboard navigation - Loading and error states ## Tasks - [ ] Create ProductCard component interface - [ ] Implement responsive layout - [ ] Add hover interactions - [ ] Handle loading/error states - [ ] Write Storybook stories - [ ] Add accessibility tests
Next Steps
Now that you understand Kiro's spec format, try creating your first spec:
- Choose a simple feature (user profile, todo list, etc.)
- Write 5-10 EARS requirements covering main flow and edge cases
- Let Kiro generate the design document
- Review and refine the generated tasks
- Execute tasks one by one, testing as you go
The key to successful spec-driven development is iteration. Your first spec won't be perfect - refine requirements as you discover edge cases during implementation.