description: Generate comprehensive requirements for a specification argument-hint: arguments: feature-name: $1 # Requirements Generation - **Mission**: Generate comprehensive, testable requirements in EARS format based on the project description from spec initialization - **Success Criteria**: - Create complete requirements document aligned with steering context - Use proper EARS syntax for all acceptance criteria - Focus on core functionality without implementation details - Update metadata to track generation status ## Core Task Generate complete requirements for feature **$1** based on the project description in requirements.md. ## Execution Steps 1. **Load Context**: - Read `{{KIRO_DIR}}/specs/$1/spec.json` for language and metadata - Read `{{KIRO_DIR}}/specs/$1/requirements.md` for project description - **Load ALL steering context**: Read entire `{{KIRO_DIR}}/steering/` directory including: - Default files: `structure.md`, `tech.md`, `product.md` - All custom steering files (regardless of mode settings) - This provides complete project memory and context 2. **Read Guidelines**: - Read `{{KIRO_DIR}}/settings/rules/ears-format.md` for EARS syntax rules - Read `{{KIRO_DIR}}/settings/templates/specs/requirements.md` for document structure 3. **Generate Requirements**: - Create initial requirements based on project description - Group related functionality into logical requirement areas - Apply EARS format to all acceptance criteria - Use language specified in spec.json 4. **Update Metadata**: - Set `phase: "requirements-generated"` - Set `approvals.requirements.generated: true` - Update `updated_at` timestamp ## Important Constraints - Focus on WHAT, not HOW (no implementation details) - All acceptance criteria MUST use proper EARS syntax - Requirements must be testable and verifiable - Choose appropriate subject for EARS statements (system/service name for software) - Generate initial version first, then iterate with user feedback (no sequential questions upfront) ## Tool Guidance - **Read first**: Load all context (spec, steering, rules, templates) before generation - **Write last**: Update requirements.md only after complete generation - Use **WebSearch/WebFetch** only if external domain knowledge needed ## Output Description Provide output in the language specified in spec.json with: 1. **Generated Requirements Summary**: Brief overview of major requirement areas (3-5 bullets) 2. **Document Status**: Confirm requirements.md updated and spec.json metadata updated 3. **Next Steps**: Guide user on how to proceed (approve and continue, or modify) **Format Requirements**: - Use Markdown headings for clarity - Include file paths in code blocks - Keep summary concise (under 300 words) ## Safety & Fallback ### Error Scenarios - **Missing Project Description**: If requirements.md lacks project description, ask user for feature details - **Ambiguous Requirements**: Propose initial version and iterate with user rather than asking many upfront questions - **Template Missing**: If template files don't exist, use inline fallback structure with warning - **Language Undefined**: Default to Japanese if spec.json doesn't specify language - **Incomplete Requirements**: After generation, explicitly ask user if requirements cover all expected functionality - **Steering Directory Empty**: Warn user that project context is missing and may affect requirement quality ### Next Phase: Design Generation **If Requirements Approved**: - Review generated requirements at `{{KIRO_DIR}}/specs/$1/requirements.md` - **Optional Gap Analysis** (for existing codebases): - Run `/prompts:kiro-validate-gap $1` to analyze implementation gap with current code - Identifies existing components, integration points, and implementation strategy - Recommended for brownfield projects; skip for greenfield - Then `/prompts:kiro-spec-design $1 -y` to proceed to design phase **If Modifications Needed**: - Provide feedback and re-run `/prompts:kiro-spec-requirements $1` **Note**: Approval is mandatory before proceeding to design phase.