---
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>
- **Role**: Produce a thorough, testable requirements document in EARS format, grounded in the project description established during initialization.
- **Success Criteria**:
  - Requirements document fully captures the intended scope
  - Every acceptance criterion follows valid EARS patterns and is verifiable
  - Content focuses on observable behavior, not implementation choices
  - Specification metadata is updated to reflect generation status
</background_information>

<instructions>
## Core Task
Generate the complete requirements document for feature **$1** using the project description stored in `requirements.md`.

## Execution Steps

1. **Load Spec and Steering Context**:
   - Read `{{SDD_DIR}}/specs/$1/spec.json` to obtain language setting and current metadata
   - Read `{{SDD_DIR}}/specs/$1/requirements.md` for the project description
   - Read the entire `{{SDD_DIR}}/steering/` directory:
     - Core files: `product.md`, `tech.md`, `structure.md`
     - All custom steering files
     - This context shapes requirement framing, terminology, and scope boundaries

2. **Load Generation Guidelines**:
   - Read `{{SDD_DIR}}/settings/rules/ears-format.md` for correct EARS syntax and pattern selection
   - Read `{{SDD_DIR}}/settings/templates/specs/requirements.md` for document structure expectations

3. **Generate Requirements**:
   - Write an introduction summarizing the feature intent
   - Organize requirements into logical, cohesive groups
   - Apply EARS patterns to every acceptance criterion
   - Use the language and terminology from the steering context
   - Produce the initial draft immediately — iterate based on user feedback rather than asking sequential questions upfront

4. **Update Specification Metadata**:
   - Set `phase: "requirements-generated"`
   - Set `approvals.requirements.generated: true`
   - Refresh `updated_at` to current ISO 8601 timestamp

## Important Constraints
- Describe WHAT the system must do, never HOW it should be built
- All acceptance criteria must be objectively testable
- Requirement headings MUST carry a leading numeric ID (e.g., "Requirement 1", "2. Payment Flow") — alphabetic IDs such as "Requirement A" are forbidden
- Select the EARS subject from the actual system or service name, not a generic placeholder
- Produce a complete draft first; refine with user feedback afterward
</instructions>

## Tool Guidance
- **Read before writing**: Load all context (spec metadata, steering, rules, template) prior to generation
- **Write last**: Update `requirements.md` only once generation is complete
- Use **WebSearch/WebFetch** only when external domain knowledge is genuinely necessary

## Output Description
Respond in the language specified in `spec.json`:

1. **Requirements Summary**: 3–5 bullet points naming the major requirement areas covered
2. **Document Status**: Confirm that `requirements.md` and `spec.json` metadata were both updated
3. **Next Steps**: Explain the approval and continuation options available to the user

**Formatting Rules**:
- Use Markdown headings for clarity
- Wrap file paths in code spans
- Keep the summary under 300 words

## Safety & Fallback

### Error Handling
- **No Project Description**: If `requirements.md` contains no description, ask the user to provide feature details before proceeding
- **Unclear Scope**: Produce an initial draft and invite iterative feedback rather than blocking on upfront questions
- **Template Missing**: Fall back to an inline document structure with a visible warning noting the missing template
- **Language Not Set**: Default to English (`en`) when `spec.json` omits a language value
- **Incomplete Coverage**: After generation, explicitly confirm with the user whether the requirements capture all expected functionality
- **Empty Steering Directory**: Warn that project context is absent and requirement quality may be reduced
- **Non-Numeric Headings**: If existing headings use alphabetic IDs, normalize them to numeric IDs and maintain consistency throughout the document

### Next Phase: Design Generation

**When Requirements Are Accepted**:
- Review the document at `{{SDD_DIR}}/specs/$1/requirements.md`
- **Optional** — run `/sdd:validate-gap $1` to surface gaps against the existing codebase (recommended for brownfield projects)
- Proceed with `/sdd:spec-design $1` or `/sdd:spec-design $1 -y` to auto-approve and continue

**When Changes Are Needed**:
- Provide specific feedback and re-run `/sdd:spec-requirements $1`

**Note**: Requirements must be approved before the design phase can begin.

think
