Feature Specs - Specs - Features - Docs - Kiro Loading image... Product * About Kiro * IDE * CLI * Web * Mobile * Crew * Pricing * Downloads For * Enterprise * Startups * Students Community * Overview * Ambassadors * Discord * Events * Powers * Shop * Showcase Resources * Docs * Blog * Changelog * FAQs * Report a bug * Suggest an idea * Billing support Social * * * * * * * English Site Terms License Responsible AI Policy Legal Privacy Policy Cookie Preferences English Loading image... * Apps * CLI * Web * Enterprise * Pricing * Docs * Community * Resources SIGN IN DOWNLOADS Loading image... Get Started Installation Authentication Your first project Models Overview Available models Reasoning effort Features How Kiro works Specs Feature Specs Requirements-First Design-First Bugfix Specs Quick Spec Plan mode Analyze Requirements Correctness Best practices Steering Hooks MCP Permissions Custom agents Agent Skills Powers Cloud sessions Compaction Kiroignore Checkpoints and rewind Built-in tools Configuration scopes IDE 1.x What's new in 1.0 Setup & First Run Editor Chat Experimental Troubleshooting 0.x reference CLI What's new in 3.0 Setup & First Run Terminal UI Chat Voice mode Headless mode ACP Auto complete Experimental 2.x reference Crew Quick start Installation Running 24/7 Chat Agent Capabilities Features Interfaces Apps System & storage Configuration Security Troubleshooting Web Setup & First Run Identity Center Connect your repositories Working with the agent Autonomous mode Automations Memory Configuration Sync Sandbox Mobile - Preview Overview Commands and Reference CLI commands Slash commands Built-in tools Exit codes Settings Billing Overview Managing your subscription Upgrading your plan Downgrading your plan Cancelling your plan Purchasing add-on credits Managing your payments Managing usage notifications Managing your taxes Contacting billing support Deleting your account Related questions Enterprise Concepts Onboarding quickstart Connecting your identity provider Deployment options Subscribe your team Manage subscriptions Governance Monitor and track Settings Managed updates Billing IAM Supported regions Privacy and Security Overview Data protection Code references Compliance validation Infrastructure security IAM permissions Firewalls, proxies, and data perimeters VPC endpoints (AWS PrivateLink) Guides Overview Language support Learn by playing Migration Migrating from Q Developer Migrating from VSCode Upgrading from Q CLI * Docs * * Features * * Specs * * Feature Specs Copy page View as Markdown Feature Specs Copy page View as Markdown Feature Specs provide a structured approach to building new features, guiding you through requirements gathering, technical design, and implementation planning. Depending on your starting point, whether you have clear user requirements or a technical design in mind, you can choose between two workflow variants that adapt to your development process. Key Benefits Structured approach - Clear phases guide you from idea to implementation Flexibility - Choose the workflow that matches your starting point Documentation - Automatic generation of requirements and design docs Tracking - Monitor progress across discrete implementation tasks Collaboration - Shared artifacts for product and engineering alignment When to Use Feature Specs Best for: * Complex features requiring structured planning * Features with multiple implementation tasks * Projects needing documentation for team collaboration * Features where requirements or design need iteration Not ideal for: * Bug fixes (use Bugfix Specs instead) * Exploratory coding without clear goals Workflow Variants Feature Specs support two workflow variants to accommodate different development scenarios. Choose the workflow that best matches your starting point and project constraints. Requirements-First Start with the behavior of the system you want to create, captured as requirements, then generate technical design and implementation tasks. Loading diagram... When to use: * You know the behavior of the system you want to build * Architecture is flexible and can be designed to meet needs * Building product features driven by customer feedback * Starting a greenfield project without technical constraints * Working in a product-led organization Flow: Requirements → Design → Tasks Design-First Start with technical design (architecture or low-level design), then derive feasible requirements and implementation tasks. Loading diagram... When to use: * You have an architecture in mind (high-level design) * You want to start with implementation behavior through pseudocode and algorithms (low-level design) * System must meet strict non-functional requirements (latency, throughput, compliance) * Porting design documents from other tools into Kiro * Exploring technical feasibility before committing to scope Flow: Design → Requirements → Tasks Quick Comparison Requirements-First Design-First Start with System behavior, captured as requirements Technical design, architecture or pseudocode Generate Design from requirements Requirements from design Best for Product-driven development Technically-constrained or design-driven projects Ensures Desired behavior is specified Technical feasibility Flexibility Implementation can adapt Requirements can adapt Tip For well-understood features where you trust Kiro's output, Quick Spec runs all three phases automatically without approval gates between them. You answer clarifying questions up front and land directly on the task list. Requirements with EARS Notation The requirements.md file uses EARS (Easy Approach to Requirements Syntax) notation to provide structured, testable requirements. Each requirement follows this pattern: WHEN [condition/event] THE SYSTEM SHALL [expected behavior] For example: WHEN a user submits a form with invalid data THE SYSTEM SHALL display validation errors next to the relevant fields This structured approach offers several benefits: * Clarity : Requirements are unambiguous and easy to understand * Testability : Each requirement can be directly translated into test cases * Traceability : Individual requirements can be tracked through implementation * Completeness : The format encourages thinking through all conditions and behaviors Analyzing requirements before design Before moving from requirements to design, you can ask Kiro to analyze your requirements for logical inconsistencies, ambiguities, conflicting constraints, and gaps. Select Analyze Requirements from the chat options or the Continue dropdown in the editor after requirements are generated. Learn more about Analyze Requirements → Design Documentation The design.md file documents technical architecture, sequence diagrams, and implementation considerations. It captures the big picture of how the system will work, including components and their interactions. Loading diagram... Getting Started Feature Specs start like any other spec - see Getting started for the per-surface steps. When Kiro asks for your intent, choose Feature , then pick your workflow: Requirements-First or Design-First . For well-understood features where you don't need approval gates between phases, select Quick Spec instead. You can also set a default workflow in your Kiro settings to skip the selection step. Learn More Best Practices Tips for effective Feature Spec usage Page updated: August 4, 2026 Specs Requirements-First