/kiro-spec-requirements

<meta> description: Generate comprehensive requirements for a specification argument-hint: <feature-name> arguments: feature-name: $1 </meta>

Requirements Generation

<background_information>

• **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
• Follow the project's EARS patterns and constraints for all acceptance criteria
• Focus on core functionality without implementation details
• Update metadata to track generation status

</background_information>

<instructions>

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)
• 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)
• Requirement headings in requirements.md MUST include a leading numeric ID only (for example: "Requirement 1", "1.", "2 Feature ..."); do not use alphabetic IDs like "Requirement A".

</instructions>

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 English (`en`) 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
• **Non-numeric Requirement Headings**: If existing headings do not include a leading numeric ID (for example, they use "Requirement A"), normalize them to numeric IDs and keep that mapping consistent (never mix numeric and alphabetic labels).

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.