| name | sabatina-prd |
| description | Sabatina o usuario com perguntas estruturadas antes de executar trabalho grande; produz PRD completo ao final, com entregavel primario como skill ou interface. Use quando o pedido for vago, ambicioso, ou antes de codar feature nova. |
Skill: Sabatina antes de executar → PRD
Objetivo
Nao executar codigo nem criar arquivos permanentes ate ter clareza suficiente. Ao final, entregar um PRD em Markdown que o usuario possa colar em plans/in-progress/ ou revisar.
Quando usar
- Pedido aberto (“quero um sistema de…”, “melhora isso”).
- Antes de CRUD, nova tela, integracao ou mudanca arquitetural.
- Quando nao esta obvio se o entregavel e skill (playbook/agente) ou interface (
app/).
Fluxo obrigatorio
- Declarar que esta em modo sabatina e que so depois do PRD vem execucao.
- Fazer perguntas em rodadas (3 a 7 rodadas conforme complexidade). Cada rodada: poucas perguntas objetivas; aguardar respostas antes da proxima.
- Se existir ferramenta de perguntas estruturadas (ex.: AskQuestion), use para escolhas multiplas e prioridades.
- Cobrir no minimo os blocos abaixo (pule apenas o que for explicitamente “nao se aplica”).
Bloco A — Problema e sucesso
- Qual dor concreta resolvemos? Para quem?
- O que significa “pronto” / metrica de sucesso?
- O que nao fazer (fora de escopo)?
Bloco B — Usuario e canal
- Quem e o usuario primario: equipe interna (agente/chat) ou externo (produto no browser)?
- O fluxo precisa funcionar sem IA aberta? Precisa login/multiusuario?
Bloco C — Skill versus interface
- O entregavel principal e repetibilidade para agente (criterios, checklist, governanca) ou experiencia em produto (telas, botoes)?
- Se 80% do valor pudesse vir de uma skill em
docs/guides/ ou nas pastas */skills/ do repo (espelhadas), bastaria?
- Consultar mentalmente
docs/00-DOC-STANDARDS.md (secao Skill versus interface).
Bloco D — Dados e integracoes
- Entradas/saidas, sistemas externos, persistencia, LGPD/sensivel.
Bloco E — Restricoes
- Prazo, stack fixa, design system, orcamento de tokens, “nao usar X”.
Bloco F — Artefatos
- Onde o PRD deve viver:
plans/in-progress/ (preferido) ou revisao antes?
- Relatorios intermediarios da conversa: apenas em chat ou salvar rascunho em
temp/?
Saida: formato do PRD
Ao terminar as perguntas, gerar um unico documento Markdown com estas secoes:
- Titulo e resumo (1 paragrafo)
- Objetivo e nao-objetivos
- Personas / usuarios
- Entregavel primario: Skill ou Interface — decisao explicita + justificativa curta
- Fluxos principais (bullet ou passos numerados)
- Dados e integracoes
- Requisitos funcionais (lista priorizada: P0/P1/P2)
- Requisitos nao-funcionais (performance, seguranca, acessibilidade se UI)
- Criterios de aceitacao (testaveis)
- Riscos e perguntas em aberto
- Proximos passos sugeridos (docs → skill → codigo, na ordem que fizer sentido)
Regras
- Nao criar codigo de producao durante a sabatina.
- Rascunhos da sessao que forem so direcionamento ou relatorio descartavel → orientar uso de
temp/ (ver skill organizar-temp-repositorio).
- Se o usuario pedir para “ja implementar”, responder que o PRD vem primeiro; pode oferecer PRD “minimo” em uma unica rodada extra se for caso trivial.
Referencias no repo
docs/00-DOC-STANDARDS.md — Skill versus interfaceplans/ — destino natural do PRD maduro- Skill
relatorio-deck-html/ (em qualquer pasta */skills/ espelhada) — opcional: apresentacao HTML a partir do PRD (JSON + script)
