Gerador de PRD para Software

O que você leva

• PRD estruturado e acionável para discussão, estimativa, priorização e execução.
• De ideia solta a PRD pronto para refinamento com engenharia em uma conversa guiada.
• Problema: Times iniciam desenvolvimento com contexto incompleto, métricas vagas e critérios de aceite fracos, gerando retrabalho, desalinhamento e entregas difíceis de validar.
• Fluxo: Criar

Exemplo de pedido pronto

Tenho uma ideia de feature: permitir que clientes B2B paguem faturas por Pix dentro do portal. Escreva um PRD, mas faça perguntas antes se faltar contexto.

Esta é uma das skills que a gente deixa aberta pra leitura. O arquivo abaixo é exatamente o que quem tem o catálogo completo recebe — entrada, passos, revisão e formato de saída. Use no seu assistente e adapte ao seu contexto.

---
name: "gerador-prd-software"
description: "Gera PRDs de software em PT-BR com perguntas de descoberta, escopo, métricas, histórias, critérios de aceite, riscos, LGPD e rollout."
---

# Gerador de PRD para Software

Use esta skill para transformar uma ideia de produto, feature ou melhoria em um PRD claro, testável e pronto para alinhamento com produto, design, engenharia e negócio. O objetivo é reduzir retrabalho: explicitar problema, escopo, não-escopo, métricas, critérios de aceite, riscos, hipóteses e decisões pendentes.

## Quando Usar

- Antes de iniciar desenvolvimento de feature em SaaS, app, portal, e-commerce ou sistema interno.
- Para converter ideia de founder, cliente, comercial ou suporte em escopo discutível.
- Em refinamento de backlog, planejamento de sprint, kickoff técnico ou discovery.
- Para revisar PRDs existentes e encontrar métricas vagas, critérios fracos ou riscos omitidos.
- Para features com IA, pagamentos, dados pessoais, integrações fiscais ou fluxos críticos, sempre com revisão humana especializada.

Não use como contrato, parecer jurídico, laudo de segurança, especificação bancária definitiva ou substituto de discovery real com usuários.

## Resultado Esperado

Um PRD em Markdown, pronto para colar em Google Docs, Notion, Confluence, Jira, Linear ou GitHub Issues, contendo: perguntas de descoberta, hipóteses/TBDs, resumo executivo, problema, objetivos, KPIs, personas, escopo, não-objetivos, histórias, critérios de aceite, requisitos técnicos, dados/LGPD, riscos, dependências e rollout.

## Entradas Necessarias

Peça ou confirme, no mínimo:

- Ideia da feature e problema que resolve.
- Público-alvo/personas e jornada atual.
- Objetivo de negócio e métricas desejadas.
- Plataforma: web, mobile, API, backoffice, portal do cliente etc.
- Stack, sistemas envolvidos e integrações conhecidas; se não souber, marcar como TBD.
- Dados tratados: nome, e-mail, CPF, CNPJ, dados bancários, dados sensíveis, logs, documentos fiscais.
- Restrições de prazo, orçamento, dependências, compliance ou operação.
- Riscos conhecidos e áreas que precisam aprovar: produto, engenharia, jurídico/DPO, financeiro, segurança, suporte.

Se faltarem informações, faça pelo menos 2 perguntas antes de redigir. Se o usuário pedir para seguir mesmo assim, liste hipóteses explicitamente.

## Processo

1. **Triagem do pedido**: identifique tipo de feature, público, criticidade, dados envolvidos e se há domínio regulado.
2. **Perguntas de descoberta**: pergunte apenas o necessário para remover ambiguidades críticas. Priorize problema, métrica, usuário, restrições e integrações.
3. **Hipóteses e TBDs**: se algo não foi informado, não invente. Use: `Hipótese`, `TBD` ou `Validar com [área]`.
4. **Estruture o PRD**:
   - Resumo executivo.
   - Contexto e problema.
   - Objetivos e não-objetivos.
   - Critérios de sucesso/KPIs com número, período e fonte de medição quando possível.
   - Personas e principais jornadas.
   - Escopo funcional.
   - Histórias de usuário no formato: Como [persona], quero [ação], para [benefício].
   - Critérios de aceite testáveis em formato checklist ou Given/When/Then.
   - Requisitos técnicos e integrações, separando fatos de hipóteses.
   - Dados, privacidade, segurança e LGPD.
   - Analytics, eventos e logs necessários.
   - Riscos, dependências, plano de rollout e rollback.
   - Perguntas em aberto e donos sugeridos.
5. **Para features com IA**: inclua qualidade esperada, exemplos bons/ruins, avaliação humana, fallback, limites de automação, monitoramento, viés, alucinação e canal de contestação quando afetar usuário.
6. **Para pagamentos/fiscal**: trate Pix, boleto, cartão, conciliação, chargeback, NFS-e/NF-e, CNPJ e dados bancários como pontos a validar com financeiro/compliance/fornecedor.
7. **Revisão final**: verifique se cada requisito é claro, mensurável, testável e não contradiz restrições informadas.

## Ferramentas E Artefatos

- **Documentação**: Google Docs, Notion, Confluence, Microsoft Word.
- **Backlog/projetos**: Jira, Linear, GitHub Issues, GitLab Issues, Azure DevOps, Trello.
- **Design/discovery**: Figma, FigJam, Miro, Maze, Hotjar.
- **Comunicação**: Slack, Microsoft Teams.
- **Artefatos gerados**: PRD, feature spec, histórias, critérios de aceite, épicos, checklist de discovery, riscos, plano de rollout, lista de eventos de analytics.

## Exemplo Brasileiro

Pedido: “Quero permitir que clientes B2B paguem faturas por Pix dentro do portal.”

Boa resposta deve perguntar, por exemplo: qual sistema financeiro emite as faturas? O Pix será via PSP/banco já contratado? A baixa precisa ser automática? Quais dados pessoais/bancários serão exibidos? Depois, gerar PRD com hipóteses marcadas: provedor Pix TBD, prazo de expiração do QR Code, conciliação, comprovante, status de pagamento, logs, permissões por perfil, LGPD, suporte para falha, piloto com 20 clientes e rollback para boleto/transferência.

Outros casos brasileiros: segunda via de NFS-e no portal do cliente, assistente de suporte com IA em português brasileiro, dashboard financeiro para PME, busca em base de conhecimento de software house.

## Criterios De Qualidade

- Faz perguntas quando o contexto é insuficiente; não preenche lacunas críticas como fato.
- PRD diferencia claramente fatos, hipóteses, TBDs e decisões pendentes.
- KPIs são mensuráveis: exemplo, “reduzir chamados sobre pagamento em 25% em 60 dias”, não “melhorar experiência”.
- Critérios de aceite são testáveis por QA/engenharia.
- Inclui escopo e não-objetivos para evitar crescimento invisível.
- Requisitos técnicos não assumem stack, APIs ou integrações não informadas.
- Riscos têm impacto, mitigação e dono sugerido.
- Inclui rollout gradual, monitoramento e plano de rollback quando a feature for crítica.
- Para IA, inclui avaliação, limites, fallback humano e monitoramento.

## Cuidados, LGPD E Escalacao Humana

- Este PRD não é parecer jurídico, fiscal, financeiro, bancário ou de segurança.
- Em dados pessoais, orientar minimização, finalidade, retenção, base legal a validar, controle de acesso, logs e descarte.
- Escalar para jurídico/DPO quando houver dados sensíveis, biometria, menores, decisão automatizada, compartilhamento com terceiros ou dúvida de base legal.
- Escalar para financeiro/compliance em Pix, boleto, cartão, antifraude, inadimplência, conciliação, dados bancários ou cobrança.
- Escalar para engenharia/segurança em autenticação, autorização, criptografia, disponibilidade, performance, auditoria, integrações críticas ou incidentes.
- Proibido prometer “conformidade LGPD garantida”, inventar contrato de API, sugerir retenção indefinida de CPF/dados bancários ou omitir revisão humana em fluxos de alto impacto.

## Smoke Test

Prompt: “Tenho uma ideia de feature: permitir que clientes B2B paguem faturas por Pix dentro do portal. Escreva um PRD, mas faça perguntas antes se faltar contexto.”

Passa se: fizer pelo menos 2 perguntas relevantes ou listar hipóteses/TBDs; gerar PRD com problema, KPIs, histórias, critérios de aceite, não-objetivos, requisitos técnicos, LGPD/segurança, riscos, rollout e pendências; não inventar provedor Pix, stack ou conformidade regulatória como certeza.