Obter PRD
Visão Geral
get-prd transforma um pedido vago em um PRD aprovado em uma única passada contínua. Ele mescla três fluxos de trabalho que geralmente são executados separadamente:
- Entrevista baseada em árvore de decisão — mapeie cada decisão como uma árvore, trabalhe a fronteira da árvore por fronteira em rodadas e dê uma recomendação para cada pergunta. Esta é a mecânica que faz uma entrevista convergir em vez de divagar.
- Extração de intenção — capture o que o usuário realmente quer, não o que ele acha que deveria querer, com um número de confiança explícito em cada etapa. Esta é a disciplina que impede o agente de preencher lacunas silenciosamente.
- Redação de especificação — escreva os requisitos em um artefato estruturado com limites, critérios de sucesso e um ponto de aprovação. Esta é a entrega que o planejamento downstream consome.
A razão para mesclá-los é que separá-los perde contexto. Quando a entrevista é um skill e a redação da especificação é outro, o segundo skill começa frio: ele pergunta novamente o que o primeiro skill já aprendeu, ou assume silenciosamente respostas que nunca foram dadas. Um PRD escrito a partir de um resumo desatualizado é pior do que nenhum PRD, porque parece autoritativo.
Duas consequências da mesclagem, ambas intencionais:
- Este skill é longo. Ele carrega a metodologia completa de todas as três fases em vez de delegar para outros skills. Siga os passos em ordem; não pule para o modelo.
- Este skill nunca delega a entrevista. O mecanismo de entrevista vive aqui. Não invoque outro skill para fazer as perguntas.
A saída é um PRD abrangente salvo em docs/PRD.md (ou docs/prd/<nome>.md), aprovado pelo usuário, pronto para get-tasks e get-design.
Para novos usuários ou conceitos em estágio inicial, o get-prd incorpora lentes de descoberta para refinamento de ideias, mapeamento de restrições não funcionais e definições de entidades/relacionamentos principais diretamente no documento, de modo que nenhum skill separado de esquema ou refinamento seja necessário.
Quando Usar
Use este skill quando:
- O usuário está iniciando um novo aplicativo, sistema, funcionalidade ou mudança significativa e nenhum documento de requisitos existe ainda
- O usuário disser "get prd", "bikin PRD", "buat PRD", "mau bikin sistem baru" ou "mau develop X"
- O usuário pedir para ser questionado, entrevistado ou ter suas ideias estressadas em direção a uma especificação
- O pedido é convencional e subespecificado ("construa um dashboard para mim", "torne isso mais rápido") e você não consegue afirmar o que significa "pronto"
- Você está prestes a planejar ou construir algo que levaria mais de um dia, e nenhum requisito escrito existe
Quando NÃO usar:
- Correções de bugs, correções de erros de digitação, renomeações e operações mecânicas
- Um PRD ou especificação já existe e o usuário quer mudar uma pequena parte dele — altere o documento diretamente
- Pedidos puramente informacionais ("como isso funciona?")
- O usuário explicitamente quer pular a documentação e começar a construir — respeite isso, mas aponte o risco uma vez
- Contextos não interativos (pipelines de CI, execuções agendadas, loops autônomos). Este skill requer um usuário responsivo ao vivo. Se o pedido for subespecificado em um contexto não interativo, sinalize-o como um bloqueador em vez de adivinhar.
O Processo
get-prd executa em oito fases. Cada fase tem uma condição de saída. Não avance para além de uma fase cuja condição de saída não foi cumprida.
0. Gate de escopo -> isso é uma capacidade ou várias?
1. Semente de hipótese -> o que acho que eles querem, e quão certo estou?
2. Construir a árvore -> quais decisões existem, e quais estão na fronteira?
3. Perguntas em rodadas -> pergunte a fronteira, uma rodada de cada vez
4. Sondagem de intenção -> quer vs. deveria-querer
5. Reafirmar -> diga de volta, nas palavras deles
6. Verificação de lacunas-> o que o PRD precisa que a entrevista não produziu?
7. Escrever e aprovar -> o PRD, então um sim explícito
Princípios Universais para o Entrevistador
- Correspondência de Linguagem Natural: Sempre converse no idioma preferido do usuário. Se o usuário iniciar a conversa em português (por exemplo, "criar PRD do aplicativo de ponto"), conduza toda a entrevista calorosamente em português, mantendo os termos técnicos padrão da indústria intactos (critérios de aceitação, esquema, endpoint, payload). Se eles falarem inglês, conduza em inglês. Nunca force uma entrevista em inglês a um usuário que perguntou em outro idioma.
- Tom Empático e Não Intimidador: Os usuários geralmente chegam com ideias brutas e não formadas. Nunca interrogue ou os faça sentir inadequados por falta de terminologia técnica. Guie-os pacientemente: traduza seus problemas de negócio em escolhas técnicas e sempre anexe sua resposta recomendada (
-> Recomendação: ...) para que eles só precisem reagir em vez de pensar do zero. - As 3 Perguntas de Ouro para Ideias Vagas / em Estágio Inicial: Quando um usuário apresentar uma ideia breve de uma frase (por exemplo, "quero criar um SaaS tipo Notion para receitas culinárias"), ancore a fronteira em torno de três pilares centrados no ser humano antes de discutir pilhas tecnológicas:
- Persona Alvo e Contexto: Quem está usando, onde e em que situação?
- A Jornada do Usuário Estrela do Norte: Qual é o fluxo de ação mais importante do início ao fim que deve ser bem-sucedido neste aplicativo?
- Escopo do MVP: Quais recursos são absolutamente necessários no primeiro dia e quais são deliberadamente adiados para a próxima etapa?
Fase 0: Gate de Escopo
A maioria dos pedidos descreve uma capacidade. Se este descrever, diga em uma linha e vá para a Fase 1. Esta fase existe para a exceção.
Detecção. Decomponha antes de escrever qualquer coisa quando um único pedido agrupar várias capacidades testáveis independentemente:
- O pedido nomeia capacidades distintas com seus próprios consumidores ou dados (identidade, faturamento, notificações, relatórios)
- Os critérios de aceitação se agrupam em clusters que poderiam ser entregues e verificados separadamente
- Uma capacidade poderia ser cortada ou substituída sem reescrever os requisitos das outras
Quando detectado, proponha um mapa de capacidades antes de qualquer rodada de entrevista. Pequeno e revisável — uma tabela de módulos mais uma ordem de construção, não um plano de projeto:
# Mapa de Capacidades: [Nome da Iniciativa]
| Id do módulo | Responsabilidade | Depende de |
|---|---|---|
| identidade | Contas, sessões, SSO | - |
| faturamento | Planos, faturas, pagamentos | identidade |
| notificações | Fan-out de e-mail e webhook | identidade |
| relatorios | Dashboards de uso | faturamento, notificações |
Ordem de construção: identidade -> faturamento, notificações -> relatorios
Regras para o mapa:
- Ids de módulo estáveis. Em kebab-case, escolhidos uma vez, nunca renomeados. O planejamento downstream seleciona o trabalho por esses ids.
- Direção da dependência, sem ciclos. As setas apontam em uma direção. Se dois módulos precisam um do outro, eles são um módulo.
- As interfaces vivem no limite. O mapa registra que
faturamentodepende deidentidade; o contrato entre eles pertence ao PRD do módulo provedor.
O mapa é um gate. Peça ao usuário para aprovar os limites dos módulos, a direção das dependências e a ordem de construção antes de entrevistar para qualquer módulo individual. Errar o mapa é caro; revisar dez linhas não é.
Em seguida, execute as Fases 1-7 uma vez por módulo, na ordem de construção, cada uma produzindo seu próprio docs/prd/<id-do-modulo>.md. Não escreva um PRD monolítico para uma iniciativa com vários módulos.
Condição de saída: ou o pedido é de capacidade única (diga isso explicitamente), ou um mapa de capacidades é aprovado.
Fase 1: Semente de Hipótese
Antes de perguntar qualquer coisa, escreva sua leitura atual do pedido e um número de confiança honesto.
HIPÓTESE: Você quer uma maneira de responder "como estamos indo?" na daily, e "dashboard" foi a convenção que veio à mente.
CONFIANÇA: ~30% - faltando: para quem é, o que "métricas" significa aqui e como é o sucesso
Regras:
- Uma frase para a hipótese. Se você não consegue escrevê-la em uma frase, você ainda não tem uma leitura.
- O número de confiança é uma porcentagem de 0 a 100. Isso força a honestidade: se você não consegue prever a reação do usuário às próximas três perguntas que faria, o número está errado.
- Abaixo de ~70%, acrescente uma breve razão na mesma linha nomeando o que ainda não está resolvido. Isso diz ao usuário exatamente o que a entrevista precisa descobrir.
- Atualize a hipótese e a confiança após cada rodada.
Condição de saída: uma hipótese com um número de confiança está registrada.
Fase 2: Construir a Árvore de Decisão
Mapeie o espaço de decisão antes de perguntar qualquer coisa. Cada decisão se ramifica nas decisões que dependem dela.
Objetivo: rastreador pessoal de experimentos
|
+-- O que conta como um experimento? (definir a unidade)
| |
| +-- Quais campos descrevem um? (escopo do esquema)
|
+-- De onde vêm os dados? (fonte de entrada)
| |
| +-- Entrada manual ou importação? (modelo de interação)
|
+-- Quando um experimento está "pronto"? (ciclo de vida)
|
+-- Qual sinal o encerra? (definição de sucesso)
A fronteira é toda decisão cujos pré-requisitos já estão resolvidos: as perguntas que você pode fazer agora sem adivinhar respostas que ainda não ouviu.
Duas regras que fazem isso funcionar:
- Pergunte toda a fronteira em uma rodada. Não faça uma pergunta por vez quando várias são independentes. Perguntas independentes são respondidas mais rápido juntas, e o usuário vê a forma do espaço de decisão.
- Uma pergunta cuja resposta depende de outra pergunta em aberto pertence a uma rodada posterior. Perguntá-la agora trava o enquadramento errado.
Fatos são seu trabalho, nunca do usuário. Quando uma pergunta da fronteira precisar de um fato do ambiente (sistema de arquivos, código existente, API de uma biblioteca, um valor de configuração), despache um subagente para encontrá-lo. Não pergunte ao usuário por nada que você mesmo poderia pesquisar. Não bloqueie a rodada por causa disso: a exploração é um pré-requisito não resolvido, então apenas as perguntas downstream dela esperam. Pergunte o resto da fronteira agora. Decisões são do usuário; fatos são seus.
Condição de saída: a árvore está mapeada e a primeira fronteira está identificada.
Fase 3: Perguntas em Rodadas
Pergunte a fronteira atual. Formate cada pergunta exatamente assim:
**Q1 - <título da pergunta>**: <corpo da pergunta, possivelmente vários parágrafos, geralmente com as opções candidatas descritas>
-> <sua resposta recomendada, com o raciocínio que a produziu>
Regras:
- Numere cada pergunta.
Q1,Q2, ... Reinicie a numeração por rodada. - Sempre anexe uma recomendação. O usuário reage mais rápido a uma recomendação errada do que gera uma resposta do zero. Isso também o compromete com uma hipótese sobre a qual você pode estar visivelmente errado.
- Aguarde as respostas antes de fazer a próxima rodada.
- Recompute a fronteira após cada rodada. Decisões resolvidas empurram a fronteira para fora e desbloqueiam perguntas que dependiam delas.
- Anote correções. Quando o usuário substituir uma recomendação, registre tanto a decisão quanto o raciocínio, porque a seção "Decisões Técnicas" do PRD se baseia nisso.
Por que a recomendação é importante e seu modo de falha:
- O usuário pode reagir a um palpite errado em segundos, mas pode levar minutos para produzir uma resposta do nada.
- Isso expõe suas suposições, que é o objetivo da entrevista.
- O risco é a bajulação — um usuário educado concordando com seu palpite para ser agradável. Mitigue sendo visivelmente disposto a estar errado, e ocasionalmente recomende uma direção que você espera que o usuário rejeite. Se toda recomendação for aceita na primeira tentativa, suspeite de bajulação.
Por que uma rodada de cada vez, não tudo de uma vez:
- A terceira pergunta geralmente depende da resposta da primeira; perguntar tudo de uma vez trava o enquadramento errado.
- A energia do usuário para pensar com cuidado é finita. Gaste-a rodada por rodada.
- Um lote de quinze perguntas parece uma pesquisa, não uma entrevista, e é lido superficialmente.
Condição de saída: as perguntas da rodada são respondidas e a fronteira é recalculada.
Fase 4: Sondagem de Intenção (quer vs. deveria-querer)
As respostas mais perigosas são aquelas em que o usuário diz o que uma resposta bem pensada parece em vez do que ele realmente quer. Fique atento a:
- Respostas que se encaixam no discurso de melhores práticas ("quero que seja escalável", "arquitetura limpa") sem especificidades
- Respostas que adiam para a convenção ("do jeito que a maioria dos aplicativos faz", "a abordagem padrão")
- Frases como "eu provavelmente deveria...", "acho que é suposto...", "as boas práticas de engenharia dizem..."
- Palavras da moda como objetivos — quando "moderno", "escalável" ou "robusto" é a resposta em vez de um resultado específico
Quando ouvir qualquer um desses, pergunte:
"Se você não precisasse justificar isso a ninguém, o que você realmente gostaria de ter?"
Essa única pergunta geralmente faz mais trabalho do que as cinco anteriores. Execute-a pelo menos uma vez sempre que uma resposta sinalizando sofisticação aparecer. Registre tanto a resposta declarada quanto a resposta sondada — o PRD deve refletir a segunda.
Condição de saída: pelo menos uma sondagem foi executada se qualquer resposta sinalizando sofisticação apareceu, e a resposta real está registrada.
Fase 5: Reafirmar Intenção
Quando a árvore estiver quase resolvida, escreva de volta o que você agora acha que o usuário quer. Mantenha-o conciso, use a linguagem deles e estruture-o para que eles possam confirmar ou corrigir linha por linha.
Aqui está o que acho que você quer agora:
- Resultado: <uma linha>
- Usuário: <uma linha - quem se beneficia>
- Por que agora: <uma linha - o que mudou>
- Sucesso: <uma linha - como sabemos que funcionou>
- Restrição: <uma linha - o limite determinante>
- Fora do escopo: <uma linha - o que estamos explicitamente não fazendo>
Sim / não / refinar?
Regras:
- "Fora do escopo" não é negociável. Metade do desalinhamento é discordância silenciosa sobre o que não está sendo construído.
- Cinco a oito linhas no total. Se ficar mais longo, a entrevista não terminou.
- Use as palavras do usuário onde possível; o vocabulário deles é o contrato compartilhado.
Condição de saída: uma reafirmação concreta nas palavras do usuário está registrada.
A Condição de Parada
Você terminou de entrevistar quando ambas as condições abaixo são verdadeiras:
- Você consegue prever a reação do usuário às próximas três perguntas que faria? Se sim, você tem um entendimento compartilhado.
- A fronteira está vazia? Não há decisão não resolvida cujos pré-requisitos estejam todos satisfeitos. Se a fronteira está vazia, a árvore está totalmente mapeada.
Se qualquer condição falhar, continue entrevistando.
Fase 6: Verificação de Lacunas
Antes de escrever, verifique os requisitos de conteúdo do PRD que a entrevista pode não ter coberto.
Lista de verificação de lacunas do PRD:
[ ] Qual é o limite do sistema? (o que está dentro x fora)
[ ] Quais são os critérios de sucesso mensuráveis?
[ ] Quem são os atores/usuários?
[ ] Quais são as restrições não funcionais? (latência, volume, conformidade)
[ ] Quais dependências externas existem? (serviços, APIs, bibliotecas)
[ ] Quais são as entidades de dados principais e seus relacionamentos?
[ ] Quais são os fluxos de borda / tratamento de erros?
[ ] Qual é a estratégia de rollout / migração?
Para cada item marcado como não coberto pela entrevista, faça uma pergunta de acompanhamento. Não adivinhe. Se o usuário não puder responder agora, marque-o como uma suposição documentada no PRD.
Condição de saída: cada lacuna foi abordada ou marcada como uma suposição com um plano de resolução.
Fase 7: Escrever e Aprovar
Escreva o PRD. Use este modelo, preenchendo cada seção com o que a entrevista produziu.
# PRD: [Nome do Projeto]
## 1. Resumo Executivo
> Uma linha.
## 2. Problema e Oportunidade
> Por que estamos fazendo isso? Qual problema resolve? Qual oportunidade aproveita?
## 3. Escopo
> **Dentro do escopo:**
> - Recurso A
> - Recurso B
>
> **Fora do escopo:**
> - Recurso C (adiado para v2)
> - Recurso D (não planejado)
## 4. Usuários e Atores
> | Ator | Descrição |
> |---|---|
> | Pessoa X | Pessoa que faz Y |
## 5. Jornada do Usuário (Estrela do Norte)
> O fluxo mais importante do início ao fim. O que deve funcionar perfeitamente.
## 6. Requisitos Funcionais
> | ID | Recurso | Descrição | Critérios de Aceitação |
> |---|---|---|---|
> | F1 | Funcionalidade principal | Como... | Dado... Quando... Então... |
## 7. Requisitos Não Funcionais
> | ID | Atributo | Alvo | Racional |
> |---|---|---|---|
> | NF1 | Desempenho | <200ms p95 | Experiência do usuário |
## 8. Entidades e Dados
> Definições das entidades de dados principais e seus relacionamentos.
>
> ```mermaid
> erDiagram
> USUARIO ||--o{ PEDIDO : faz
> ```
## 9. Dependências e Integrações
> Serviços, APIs, bibliotecas e outros sistemas dos quais este recurso depende.
## 10. Decisões Técnicas
> Decisões feitas durante a entrevista, com a justificativa.
## 11. Tratamento de Erros e Casos de Borda
> O que acontece quando…
## 12. Estratégia de Rollout / Migração
> Como isso chega aos usuários.
## 13. Suposições
> | Suposição | Risco se errada | Plano de Resolução |
> |---|---|---|
> | Suposição A | Risco X | Validar com... |
## 14. Métricas de Sucesso
> Como sabemos que funcionou?
## 15. Aprovação
> - [ ] Aprovado por: [Nome]
> - [ ] Data:
Regras:
- Não omita seções. Se uma seção estiver vazia porque a entrevista não a cobriu, escreva "TBD" e uma questão em aberto. Uma seção vazia documenta que a decisão não foi tomada, que é valioso.
- Use o modelo do
get-prd. Não invente sua própria estrutura. O modelo existe para que as saídas downstream possam analisar PRDs de forma confiável. - Salve em
docs/PRD.mdpara capacidades únicas oudocs/prd/<id-do-modulo>.mdpara módulos.
Gate de aprovação: antes de declarar o PRD concluído, peça uma aprovação explícita:
"Este PRD está pronto para planejamento. Você pode revisá-lo e aprová-lo?"
Não aceite um aceno de cabeça. Aguarde um "sim" explícito, ou um comentário que leve a uma revisão.
Condição de saída: o PRD está salvo no caminho correto e o usuário confirmou a aprovação.
Resumo Visual
Pedido Vago
|
v
[0. Gate de Escopo] ---> Mapa de Capacidades (se vários módulos)
|
v
[1-5. Entrevista] ---> Árvore de Decisão, Rodadas, Sondagem, Reafirmação
|
v
[6. Verificação de Lacunas] ---> Perguntas finais
|
v
[7. Escrever PRD] ---> docs/PRD.md
|
v
Aprovação do Usuário
|
v
Pronto para -> get-tasks, get-design