97 lines
4.6 KiB
Markdown
97 lines
4.6 KiB
Markdown
---
|
|
description: Generate comprehensive requirements for a specification
|
|
allowed-tools: Bash, Glob, Grep, LS, Read, Write, Edit, MultiEdit, Update, WebSearch, WebFetch
|
|
argument-hint: <feature-name>
|
|
---
|
|
|
|
# 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/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".
|
|
</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/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.
|