---
id: create-next-story
agent: sm
title: Criar a próxima story do épico
inputs: [épico, PRD shardado, docs de arquitetura]
outputs: ['docs/stories/{epicNum}.{storyNum}.story.md em status Draft']
elicit: false
modes: [interactive, yolo]
---

# Criar a próxima story do épico

**Objetivo:** transformar a próxima fatia de um épico numa story que o @dev implementa sem adivinhação
— ACs testáveis e contexto técnico colado dentro do arquivo — rastreando tudo ao PRD/épico/arquitetura.

**Pré-condições:**
- Existe um épico de origem e o PRD shardado. Sem essa âncora, **pare**: qualquer story aqui seria
  invenção (viola No Invention — Art. IV). Sinalize a lacuna para o @pm.
- Os docs de arquitetura relevantes estão acessíveis (stack, contratos, padrões). Se faltarem para a
  área da story, marque a lacuna explicitamente — não preencha com opinião.

## Passos

1. **Identifique a próxima story.** Leia o épico e o índice de stories em `docs/stories/`. Determine o
   próximo `{storyNum}` na sequência do épico. Se a story anterior não estiver concluída e for
   dependência, registre a dependência — não fure a ordem "por eficiência".
2. **Ancore no contexto.** Leia o épico de origem, a seção correspondente do PRD shardado e os docs de
   arquitetura relevantes. Extraia os FR/NFR/CON que a story deve atender. Tudo que entrar na story
   precisa rastrear a uma dessas fontes.
3. **Crie o arquivo** `docs/stories/{epicNum}.{storyNum}.story.md` a partir do template de story
   (`templates/`). Preencha título, status `Draft` e a referência ao épico de origem.
4. **Escreva critérios de aceite testáveis.** Cada AC no formato "dado X, quando Y, então Z" e
   rastreável a um FR/NFR. Nada de "funciona bem". Se um requisito do épico não couber nesta story,
   deixe-o para a próxima — não infle o escopo.
5. **Cole o contexto técnico dentro da story.** Arquivos a tocar, contratos/interfaces, dependências de
   stories anteriores, padrões do projeto a seguir, e a seção de Testing. O @dev não deveria precisar
   abrir cinco documentos para implementar.
6. **Preencha a qualidade preditiva.** Pelo tipo da story, anote a seção de integração de revisão de
   código e quais gates/agentes especializados ela provavelmente exigirá (@qa sempre; @data-engineer se
   toca schema; @ux-design-expert se toca UI). Planejar o gate na criação é mais barato que no review.
7. **Releia pela lente do dev.** "Dá pra implementar isso sem me perguntar nada?" Cada ponto de
   adivinhação vira contexto adicionado — ou uma lacuna explícita marcada para o @pm resolver.
8. **Rode o story-draft-checklist** (via `execute-checklist`). Se passa, a story permanece em `Draft`
   pronta para validação do @po. Se há lacuna de PRD/arquitetura, **sinalize** — não tape o buraco.
9. **Entregue o gate.** Story pronta → @po valida (10-point). Não valide você mesma e não implemente:
   seu entregável é o artefato story, não o commit.

## Critério de pronto (DoD)

- [ ] Arquivo `docs/stories/{epicNum}.{storyNum}.story.md` criado em status `Draft`
- [ ] Cada AC é testável ("dado/quando/então") e rastreia a um FR/NFR/CON
- [ ] Contexto técnico colado: arquivos, contratos, dependências e seção de Testing
- [ ] Seção de revisão de código + gates previstos preenchida pelo tipo da story
- [ ] story-draft-checklist executado com aprovação (ou lacunas sinalizadas ao @pm)
- [ ] Story roteada ao @po para validação — sem implementação e sem `git push`

## Falha / recuperação

- **PRD/épico não cobre o que a story precisa** → registro a lacuna e escalo ao @pm. Não invento o
  requisito que falta (No Invention — Art. IV).
- **Arquitetura ambígua para a área da story** → marco a lacuna explícita na story e sinalizo ao
  @architect; não chuto stack nem contrato.
- **story-draft-checklist reprova** → corrijo os itens que são meus (contexto, ACs, formato) e refaço.
  Se a reprovação é por lacuna de produto, devolvo ao @pm em vez de forçar a aprovação.
- **Pedido de correção de escopo no meio** → escalo para a @nexus-master (correct-course). Não corrijo
  escopo de produto por conta própria.