// Transform vague feature ideas into clear, testable requirements using EARS format. Capture user stories, define acceptance criteria, identify edge cases, and validate completeness before moving to design.
Create comprehensive steering documents for development projects. Generates project-specific standards, git workflows, and technology guidelines in .kiro/steering/ directory.
Effective communication strategies for AI-assisted development. Learn context-first prompting, phased interactions, iterative refinement, and validation techniques to get better results from Claude and other AI coding assistants.
Transform approved requirements into comprehensive technical designs. Define system architecture, component interactions, data models, and interfaces to create a blueprint for implementation.
Comprehensive testing and validation strategies for spec-driven development. Learn phase-specific validation techniques, quality gates, and testing approaches to ensure high-quality implementation.
Systematic three-phase approach to feature development using Requirements, Design, and Tasks phases. Transforms vague feature ideas into well-defined, implementable solutions that reduce ambiguity, improve quality, and enable effective AI collaboration.
Convert technical designs into actionable, sequenced implementation tasks. Create clear coding tasks that enable incremental progress, respect dependencies, and provide a roadmap for systematic feature development.
| name | requirements-engineering |
| description | Transform vague feature ideas into clear, testable requirements using EARS format. Capture user stories, define acceptance criteria, identify edge cases, and validate completeness before moving to design. |
| license | MIT |
| compatibility | Claude Code, Cursor, VS Code, Windsurf |
| metadata | {"category":"methodology","complexity":"beginner","author":"Kiro Team","version":"1.0.0"} |
Master the art of capturing what needs to be built before diving into how to build it. This skill teaches the EARS (Easy Approach to Requirements Syntax) format for creating clear, testable requirements.
Use requirements engineering when:
EARS provides consistent patterns for writing requirements that are specific, testable, and unambiguous.
Event-Response (Most Common):
WHEN [triggering event] THEN [system] SHALL [required response]
Conditional Behavior:
IF [precondition is met] THEN [system] SHALL [required response]
Complex Conditions:
WHEN [event] AND [additional condition] THEN [system] SHALL [response]
Optional Conditions:
WHEN [event] OR [alternative event] THEN [system] SHALL [response]
State-Based:
WHEN [system is in specific state] THEN [system] SHALL [behavior]
Performance:
WHEN [user action] THEN [system] SHALL [respond within X seconds/milliseconds]
Security:
IF [authentication condition] THEN [system] SHALL [security response]
Format: As a [role], I want [feature], so that [benefit]
Focus on:
Example:
As a returning customer, I want to save my payment methods, so that I can checkout faster in the future.
For each user story, define specific acceptance criteria using EARS:
Example for payment methods:
**User Story:** As a returning customer, I want to save my payment methods, so that I can checkout faster.
**Acceptance Criteria:**
1. WHEN user adds a valid credit card THEN system SHALL securely store card details
2. WHEN user adds a card with invalid number THEN system SHALL display validation error
3. WHEN user has saved cards THEN system SHALL display list during checkout
4. WHEN user selects saved card THEN system SHALL pre-fill payment form
5. WHEN user deletes saved card THEN system SHALL remove card from list
6. IF user is not authenticated THEN system SHALL redirect to login before saving card
7. WHEN user adds card THEN system SHALL mask all but last 4 digits in display
For each requirement, ask:
Edge case patterns:
**Error Handling:**
- WHEN [operation fails] THEN system SHALL [display error / retry / log]
**Boundary Conditions:**
- WHEN [value equals minimum/maximum] THEN system SHALL [specific behavior]
**Concurrent Access:**
- WHEN [multiple users access same resource] THEN system SHALL [conflict resolution]
**Empty States:**
- WHEN [collection is empty] THEN system SHALL [display empty state message]
Use this checklist:
Completeness:
Clarity:
Consistency:
Testability:
Bad: "System should be fast" Good: "WHEN user submits search THEN system SHALL return results within 2 seconds"
Bad: "System shall use Redis for caching" Good: "WHEN user requests frequently accessed data THEN system SHALL return cached results"
Bad: Only documenting happy path Good: Include WHEN/IF statements for all error conditions
Bad: "System should be user-friendly" Good: "WHEN new user completes onboarding THEN system SHALL require no more than 3 clicks to reach main dashboard"
Bad: Requirements that contradict each other Good: Review all requirements together, resolve conflicts explicitly
**User Story:** As a user, I want to upload files, so that I can share documents with my team.
**Acceptance Criteria:**
1. WHEN user selects file under 10MB THEN system SHALL accept file for upload
2. WHEN user selects file over 10MB THEN system SHALL display "file too large (max 10MB)" error
3. WHEN user selects unsupported file type THEN system SHALL display "unsupported format" error with list of allowed types
4. WHEN upload is in progress THEN system SHALL display progress indicator with percentage
5. WHEN upload completes successfully THEN system SHALL display success message with file link
6. WHEN upload fails due to network error THEN system SHALL display retry option
7. IF user is not authenticated THEN system SHALL redirect to login before upload
8. WHEN user uploads file with same name as existing file THEN system SHALL prompt for rename or replace
**Supported File Types:** PDF, DOC, DOCX, XLS, XLSX, PNG, JPG, GIF
**Maximum File Size:** 10MB
**Maximum Files Per Upload:** 5
**User Story:** As a customer, I want to search products, so that I can find items quickly.
**Acceptance Criteria:**
1. WHEN user enters search term THEN system SHALL display matching products
2. WHEN search returns results THEN system SHALL show result count
3. WHEN search returns no results THEN system SHALL display "no products found" with suggestions
4. WHEN user searches with special characters THEN system SHALL sanitize input and search
5. WHEN user submits empty search THEN system SHALL display validation message
6. WHEN results exceed 20 items THEN system SHALL paginate with 20 items per page
7. WHEN user searches THEN system SHALL return results within 2 seconds
8. WHEN user types in search box THEN system SHALL show autocomplete suggestions after 3 characters
**Search Fields:** Product name, description, category, SKU
**Minimum Search Length:** 2 characters
# Requirements Document: [Feature Name]
## Overview
[Brief description of the feature and its purpose]
## User Roles
- [Role 1]: [Description of this user type]
- [Role 2]: [Description of this user type]
## Requirements
### Requirement 1: [Name]
**User Story:** As a [role], I want [feature], so that [benefit]
**Acceptance Criteria:**
1. WHEN [event] THEN system SHALL [response]
2. IF [condition] THEN system SHALL [response]
3. WHEN [event] AND [condition] THEN system SHALL [response]
**Edge Cases:**
- [Edge case 1 and how it's handled]
- [Edge case 2 and how it's handled]
### Requirement 2: [Name]
[Continue pattern...]
## Non-Functional Requirements
- **Performance:** [Specific metrics]
- **Security:** [Security requirements]
- **Accessibility:** [Accessibility standards]
## Out of Scope
- [Items explicitly not included in this feature]
## Open Questions
- [Questions that need stakeholder input]
After completing requirements: