voltar ao catálogo

criar-prd

Cria Documentos de Requisitos de Produto (PRDs) a partir de pedidos de funcionalidade, seguindo um fluxo estruturado de esclarecimento, planejamento e redação. Gera um PRD padronizado salvo em `./docs/tasks/prd-[nome]/prd.md`, pronto para ser consumido pelas skills `criar-techspec` e `criar-tasks`. Use quando o usuário pedir para criar um PRD, definir requisitos ou documentar uma nova funcionalidade. Não use para especificações técnicas, quebra de tarefas ou planejamento de implementação.

Versão: v1.0.0Autor: Fabio de StefaniPlugin: criar-prdTags: prd, requisitos, produto, documentacao
/plugin install criar-prd@nextfit-hub-ai

Criar PRD

Restrições Inegociáveis

  • Não gere o PRD sem antes coletar respostas de clarificação via AskUserQuestion.
  • Não altere a estrutura do template em assets/prd-template.md.
  • O PRD define O QUÊ e POR QUÊ; decisões de implementação (COMO) pertencem à Tech Spec — nunca antecipar arquitetura, bibliotecas ou design técnico aqui.
  • Todo requisito funcional deve ser numerado e mensurável/verificável; afirmações vagas ("rápido", "intuitivo") são reescritas com critério objetivo.
  • O documento final deve ter no máximo 2.000 palavras.
  • O caminho de saída é sempre ./docs/tasks/prd-[nome]/prd.md — alinhado às skills criar-techspec e criar-tasks, que leem o PRD a partir desse caminho.

Procedimentos

Passo 1: Esclarecer (Obrigatório)

  1. Leia references/clarification-checklist.md e selecione os blocos pertinentes à solicitação do usuário.
  2. Formule perguntas agrupadas via AskUserQuestion, cobrindo no mínimo: problema e objetivos, usuários e histórias, funcionalidade principal, escopo (incluindo o que está fora) e design/UX.
  3. Não prossiga ao Passo 2 enquanto houver perguntas não respondidas.

Passo 2: Planejar (Obrigatório)

  1. Defina a abordagem seção por seção do PRD com base nas respostas coletadas.
  2. Identifique áreas que exigem pesquisa adicional (regras de negócio, benchmarks, normas) e use WebSearch quando necessário.
  3. Liste premissas e dependências que sustentarão a redação.
  4. Exiba o plano resumido ao usuário antes de redigir o documento.

Passo 3: Redigir o PRD (Obrigatório)

  1. Leia assets/prd-template.md e replique sua estrutura exatamente, preservando a ordem das seções: Visão Geral → Objetivos → Histórias de Usuário → Funcionalidades Principais → Experiência do Usuário → Restrições Técnicas de Alto Nível → Fora de Escopo.
  2. Foque no O QUÊ e no POR QUÊ; nunca em COMO (implementação pertence à Tech Spec).
  3. Em ## Objetivos, registre metas mensuráveis (com indicadores ou metas numéricas sempre que possível).
  4. Em ## Histórias de Usuário, use o formato Como [persona], eu quero [ação] para que [benefício]; cubra fluxos principais e casos extremos.
  5. Em ## Funcionalidades Principais, inclua requisitos funcionais numerados (RF-01, RF-02, ...) para cada funcionalidade descrita.
  6. Em ## Restrições Técnicas de Alto Nível, capture apenas restrições (integrações obrigatórias, conformidade, metas de performance, sensibilidade de dados); não proponha design.
  7. Em ## Fora de Escopo, declare explicitamente o que não será incluído e o que fica para considerações futuras.
  8. Mantenha o documento abaixo de 2.000 palavras.

Passo 4: Criar Diretório e Salvar (Obrigatório)

  1. Derive o slug em kebab-case a partir do nome da funcionalidade (ex.: "Checkout via Pix" → checkout-pix).
  2. Crie o diretório ./docs/tasks/prd-[nome]/ via Bash se ainda não existir.
  3. Salve o documento em ./docs/tasks/prd-[nome]/prd.md via Write.

Passo 5: Validar com o Checklist de Qualidade (Obrigatório)

  1. Leia references/quality-checklist.md.
  2. Verifique cada item obrigatório contra o documento gerado.
  3. Se algum item obrigatório falhar, retorne ao Passo correspondente e corrija antes de reportar.

Passo 6: Reportar Resultados

  1. Informe o caminho completo do arquivo gerado.
  2. Forneça um resumo bem breve com: problema endereçado, principais objetivos e quantidade de requisitos funcionais numerados.
  3. Não anexe o conteúdo do documento na resposta — apenas o resumo e o caminho.

Helpers Bundled

  • assets/prd-template.md — read-only. Estrutura canônica do documento final. Replicar sem alterar a ordem das seções.
  • references/clarification-checklist.md — read-only. Base para as perguntas obrigatórias do Passo 1.
  • references/quality-checklist.md — read-only. Auditoria final no Passo 5.

Tratamento de Erros

  • Usuário não respondeu às perguntas de clarificação: repita o Passo 1 com perguntas mais específicas; não suponha respostas.
  • Pedido vago ou genérico ("crie um PRD para X"): trate como contexto insuficiente e volte ao Passo 1 com perguntas focadas em problema, usuários e critério de sucesso.
  • Decisão de implementação aparecendo no rascunho (biblioteca, schema, endpoint): rebaixe para ## Restrições Técnicas de Alto Nível apenas se for restrição inegociável; caso contrário, remova e deixe para a Tech Spec.
  • Diretório ./docs/tasks/ inexistente: crie-o como parte do Passo 4; não trate como erro.
  • prd.md já existe em ./docs/tasks/prd-[nome]/: confirme com o usuário se deve sobrescrever ou usar sufixo numérico (prd-v2.md); nunca apague o arquivo anterior sem confirmação.
  • Template ausente em assets/prd-template.md: reporte o erro e interrompa — não gere PRD sem o template.