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

**⛔ REGRA ABSOLUTA — ZERO COMANDOS CLI NO OUTPUT**: Nunca escreva `/sdd:`, `sdd:spec-`, `sdd:validate-` nem nenhum slash command na resposta. O usuário opera exclusivamente pela interface gráfica.

Responda no idioma do `spec.json`, em até 200 palavras:

1. **Resumo dos Requisitos**: 3–5 bullet points com as áreas principais cobertas
2. **Status do Documento**: Confirme que `requirements.md` e `spec.json` foram atualizados
3. Finalize com: "Os requisitos estão prontos para revisão. Use o botão **Aprovar** na interface para avançar."

## Safety & Fallback

- **Sem descrição**: Peça ao usuário os detalhes da feature
- **Escopo confuso**: Gere rascunho inicial e convide feedback
- **Idioma não definido**: Use `pt-BR`
- **Steering vazio**: Avise que o contexto do projeto está ausente

**Próxima fase**: O usuário clica em "Aprovar" na interface SDD-FP — NÃO mencione comandos CLI, NÃO escreva próximos passos com slash commands.
