weseek__growi/.claude/commands/kiro/spec-requirements.md

---

description: Generate comprehensive requirements for a specification allowed-tools: Bash, Glob, Grep, LS, Read, Write, Edit, MultiEdit, Update, WebSearch, WebFetch

argument-hint:

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
  • 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

Core Task

Generate complete requirements for feature $1 based on the project description in requirements.md.

Execution Steps

1. Load Context:

   • Read .kiro/specs/$1/spec.json for language and metadata
   • Read .kiro/specs/$1/requirements.md for project description
   • Load ALL steering context: Read entire .kiro/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/settings/rules/ears-format.md for EARS syntax rules
   • Read .kiro/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".

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/specs/$1/requirements.md
• Optional Gap Analysis (for existing codebases):
  • Run /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 /kiro:spec-design $1 -y to proceed to design phase

If Modifications Needed:

• Provide feedback and re-run /kiro:spec-requirements $1

Note: Approval is mandatory before proceeding to design phase.

think