Transforma um PRD em plano de implementação faseado com fatias verticais (tracer bullets), salvo em ./plans/. Usar quando o usuário quiser quebrar um PRD em fases, criar plano de implementação, ou planejar entregas a partir de um PRD.
Esta skill é invocada quando o usuário quer transformar um PRD (Produto — Documento de Requisitos) em um plano de implementação faseado. Cada fase é uma fatia vertical — um pedaço fino que passa por todas as camadas ao mesmo tempo (banco, API, frontend, testes), entregando algo demonstrável.
O público-alvo são vibecoders — conduza a conversa de forma acolhedora, prática e sem jargões desnecessários.
Toda a comunicação deve ser em português do Brasil.
Sem interação com o usuário. Antes de fazer qualquer pergunta:
CLAUDE.md do projeto (se existir) para entender stack, regras e restrições arquiteturaisapps/, packages/, etc.)plans/*.md para encontrar PRDs existentes*-plano.md)packages/sharedUse esse contexto para fazer perguntas mais inteligentes e evitar propor fases para coisas que já existem.
"Encontrei o PRD de [nome da feature] aqui:
plans/[arquivo].md.Ele tem N histórias de Alta prioridade, Y tabelas e Z endpoints.
É esse que você quer transformar em plano de implementação?"
Leia o PRD completo antes de prosseguir.
"Encontrei mais de um PRD por aqui:
plans/[arquivo1].md— parece ser sobre [assunto em 5 palavras]plans/[arquivo2].md— parece ser sobre [assunto em 5 palavras]Qual deles você quer transformar em plano?"
"Não encontrei nenhum PRD por aqui ainda.
O prd-planejamento funciona a partir de um PRD pronto — é o documento que descreve o que você quer construir, pra quem, e como.
Se você ainda não tem um, posso te ajudar a criar com o
/novo-prd. Quer fazer isso primeiro?Ou se o PRD está em outro lugar, me diz o caminho do arquivo."
Se o usuário colou o PRD ou apontou para o arquivo antes de invocar a skill, confirme: "Vou usar esse PRD como base. Me dá um segundo para ler com calma."
Nunca avance sem ter lido o PRD completo e recebido confirmação do usuário.
Sem interação com o usuário. Analise o PRD silenciosamente:
A partir da seção "Modelo de Dados" do PRD:
Para cada história de Prioridade Alta (MVP):
Agrupe histórias que formam uma fatia vertical coerente — ou seja, histórias que juntas entregam algo demonstrável de ponta a ponta. Critérios:
Ordene os clusters pela dependência de dados:
Identifique o que precisa existir antes de qualquer fase de feature:
packages/sharedTudo isso vai para a Fase 0.
Apresente as fases ao usuário em linguagem simples. Use a metáfora de construção quando ajudar a explicar a sequência.
"Aqui está como eu dividiria a construção do [nome da feature] em etapas.
Cada etapa entrega algo que você consegue abrir no sistema e usar (ou pelo menos ver funcionando). A ideia é ir construindo em camadas — como uma casa: primeiro a fundação, depois as paredes, depois os acabamentos.
Fase 0 — Fundação (sem interface ainda, só estrutura)
- Criar as tabelas no banco
- Criar os tipos compartilhados
- Registrar as rotas (vazias por enquanto)
- Configurar auth nas rotas protegidas
Fase 1 — [Nome descritivo]
- Histórias: #N, #M
- O que você vai construir: [lista em linguagem simples]
- Ao terminar, você consegue: [descrição demonstrável]
Fase 2 — [Nome descritivo]
- Histórias: #N, #M
- O que você vai construir: [lista em linguagem simples]
- Ao terminar, você consegue: [descrição demonstrável]
[... mais fases se necessário ...]
Essa divisão faz sentido? Alguma fase parece grande demais ou pequena demais?"
Se quer juntar fases (sem conflito técnico):
"Consigo juntar sim. Ficaria assim: [descrever fase combinada]. Vai ficar maior, mas dá pra fazer. Confirma?"
Se quer quebrar uma fase:
"Posso quebrar a Fase [X] em duas partes menores:
- Opção A: [descrição]
- Opção B: [descrição] Qual faz mais sentido?"
Se quer reordenar criando conflito técnico:
"Entendo a lógica — [reconhecer o raciocínio do usuário].
O problema prático é que a Fase [X] usa coisas que só existem depois da Fase [Y]. É como querer colocar as janelas antes de ter as paredes — elas não têm onde se encaixar ainda.
O que posso fazer é reorganizar assim: [propor alternativa que honra a intenção]. Dessa forma você chega mais cedo em [o que o usuário queria]. Resolve?"
Se o usuário insistir após a explicação, respeite a escolha e documente o risco no plano.
Itere até o usuário aprovar a divisão.
Antes de escrever o plano, apresente um resumo compacto:
"Deixa eu confirmar o que vou escrever:
Projeto: [nome] Objetivo: [1 frase]
[N] fases:
- Fundação — estrutura base (banco, tipos, rotas)
- [nome] — [1 linha] → ao terminar: [demonstrável]
- [nome] — [1 linha] → ao terminar: [demonstrável]
- [nome] — [1 linha] → ao terminar: [demonstrável]
Posso montar o plano de implementação com essa estrutura?"
Nunca assuma aprovação. Só avance para o Passo 5 com um "sim" claro.
Escreva o plano no arquivo plans/<mesmo-nome-do-prd>-plano.md.
Exemplo: se o PRD é plans/gestao-de-clientes.md, o plano fica em plans/gestao-de-clientes-plano.md.
Crie o diretório plans/ se não existir.
PRD de origem:
plans/[nome-do-prd].mdCriado em: [data]
[2-3 frases descrevendo o que esta feature entrega ao usuário final. Sem jargão técnico. Extrair da "Solução Proposta" e "Definição de MVP" do PRD.]
[Parágrafo explicando como as fases foram divididas e por quê. Esse é o mapa mental do plano inteiro — o leitor entende o arco completo antes de mergulhar nos detalhes. Ex: "A Fase 0 prepara o banco e os tipos. As Fases 1 e 2 entregam o CRUD principal. A Fase 3 adiciona busca, filtros e refinamentos. Cada fase exceto a 0 é demonstrável."]
Pré-requisitos antes de começar:
Não é demonstrável. Prepara a infraestrutura que todas as fases seguintes dependem. Se o projeto já tem a fundação pronta para esta feature, pular esta fase.
Histórias cobertas: nenhuma diretamente — habilita todas as do MVP
[Decisões de implementação próprias do plano — NÃO duplicar o que o CLAUDE.md já define. Exemplos válidos: "usar soft delete (campo deletedAt) em vez de delete físico", "processar uploads de forma síncrona no MVP". NÃO incluir: "usar Drizzle ORM", "retornar { data }" — isso já está no CLAUDE.md.]
packages/shared — tipos e schemas
apps/api — banco de dados e rotas
[nome]: [colunas principais][nome]: [colunas principais]apps/web — infraestrutura de frontend
[/caminho] registrada no React Routerbun run db:migrate roda sem errobun run typecheck passa em todos os workspaces@projeto/shared sem erro de importGET /api/[x] retorna 200 com dados mock[/x] renderiza sem erro no browserAo final desta fase: [frase de uma linha descrevendo o que fica demonstrável. Ex: "É possível criar clientes e ver a lista completa na tela."]
Histórias cobertas:
Depende de: Fase 0 concluída
| Tabela | Operação | Observação |
|---|---|---|
[nome] | INSERT, SELECT | [ex: paginado, 20 por página] |
Contrato completo no PRD — aqui listamos apenas o escopo desta fase:
| Método | Rota | Auth | Descrição |
|---|---|---|---|
| POST | /api/[rota] | autenticado | [descrição curta] |
| GET | /api/[rota] | autenticado | [descrição curta + query params relevantes] |
Tela: [Nome da tela] — [/rota-no-frontend]
Modal/Drawer: [Nome]
[/rota] no browserFuncionais (comportamento do usuário):
Técnicos (padrões obrigatórios):
{ data } / { error, code } conforme CLAUDE.mdbun run typecheck e bun run lint passamRisco desta fase: [risco do PRD que se torna real nesta fase, se houver. Omitir se não houver.]
Ao final desta fase: [frase demonstrável]
Histórias cobertas:
Depende de: Fase 1 concluída [+ explicação se a dependência não for óbvia: "porque o formulário de [X] precisa buscar [Y] para o campo de seleção"]
| Tabela | Operação | Observação |
|---|
| Método | Rota | Auth | Descrição |
|---|
[Lista concreta]
Funcionais:
Técnicos:
bun run typecheck e bun run lint passamMarcar apenas quando TODOS os critérios de aceite de todas as fases estiverem verdes.
Extraído das seções "Prioridade Média" e "Prioridade Baixa" do PRD:
Criar PRD separado antes de implementar qualquer item desta lista.
[Copiar da seção "Fora do Escopo" do PRD — manter como lembrete contra scope creep.]
Após escrever o plano, apresente ao usuário:
"Pronto! Escrevi o plano em
plans/[arquivo]-plano.md.Resumo:
- O plano tem [N] fases para construir [feature]
- A Fase 0 prepara [resumo da fundação]
- A Fase 1 entrega [resumo demonstrável]
- A Fase 2 entrega [resumo demonstrável]
- [...]
- No total, cobre todas as [N] histórias de Alta prioridade do PRD
- Histórias de Média e Baixa ficaram no Pós-MVP
Esse plano captura tudo o que discutimos? Quer ajustar alguma coisa?"
Se o usuário pedir mudanças, atualize o plano e re-apresente o resumo
Só considere o plano finalizado com aprovação explícita do usuário
Após aprovação, ofereça o próximo passo:
"Para começar a Fase 0 agora, é só me dizer. Eu abro o plano, leio a primeira fase e te guio na implementação passo a passo."
POST /api/clientes) mas direcionar ao PRD para o contrato completoINCLUIR no plano (decisões duráveis que não mudam entre fases):
/api/clientes)clientes, pedidos)clienteSchema)NÃO INCLUIR no plano (detalhes que ficam desatualizados):
apps/api/src/routes/clientes.ts)createClienteHandler)createInsertSchema, sValidator)Ao analisar o PRD para determinar a ordem:
Quase todo PRD toca o banco. A Fase 0 garante que o monorepo compila e o CI passa com os novos paths — mesmo que a lógica ainda seja stub. É o tracer bullet na forma mais pura.
Se o projeto já tem as tabelas e rotas da feature (porque alguém começou antes), a Fase 0 pode ser pulada ou reduzida.
PRD em plans/gestao-de-clientes.md → Plano em plans/gestao-de-clientes-plano.md
Isso pareia os arquivos visualmente em qualquer listagem ordenada e torna a linhagem óbvia.
Para um PRD típico com 5-8 histórias MVP:
3-4 fases é o sweet spot. Mais de 5 fragmenta demais e cria ansiedade de "progresso lento". Menos de 3 cria fases densas demais para executar de uma vez.
Mais de 4 fases só se o MVP tiver 2 domínios independentes (ex: gestão de clientes + relatórios). Nesse caso, considerar se não deveria ser 2 PRDs separados.
Se ao analisar o PRD o número de fases passar de 5-6, sugira dividir em planos separados: "Esse PRD é grande. Sugiro dois planos: um para [domínio A] e outro para [domínio B]. Assim cada plano fica focado e executável. Quer dividir?"
O plano é projetado para ser consumido por um AI coding assistant (como o próprio Claude Code). Cada fase tem informação suficiente para que o assistente saiba exatamente o que construir sem precisar re-ler o PRD inteiro — mas referencia o PRD para os detalhes completos (contrato de API, modelo de dados).
Se a fase tem endpoints, eles devem estar listados na tabela com método + rota + auth. Isso alinha frontend e backend antes do código. O contrato completo (request/response/erros) fica no PRD — o plano só lista o escopo.