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:

  1. Requirements - What the system should do (EARS format)
  2. Design - How the system will work (architecture & interfaces)
  3. 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:

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

Design Document Tips

Task Organization

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:

  1. Choose a simple feature (user profile, todo list, etc.)
  2. Write 5-10 EARS requirements covering main flow and edge cases
  3. Let Kiro generate the design document
  4. Review and refine the generated tasks
  5. 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.