Geração de PRD

Gere Documentos de Requisitos de Produto (PRDs) estruturados a partir de ideias de funcionalidades.

O Que Este Skill Faz

Transforma solicitações informais de funcionalidades em PRDs completos com histórias de usuário, critérios de aceitação, requisitos funcionais, métricas de sucesso e orientações de conformidade. O resultado está pronto para implementação pela equipe de engenharia e revisão pelas partes interessadas.

Quando Usar

Ative este skill quando:

O usuário deseja documentar uma nova funcionalidade ou ideia de produto
Frases como "escrever um PRD", "criar requisitos", "documentar esta funcionalidade"
Preparação para revisão de produto, alinhamento de stakeholders ou entrega para engenharia
O usuário menciona histórias de usuário, critérios de aceitação ou métricas de sucesso
Necessidade de formalizar uma ideia vaga em documentação estruturada

Detecção de Cenário (CRÍTICO - Primeiro Passo)

Antes de gerar qualquer conteúdo de PRD, você DEVE identificar o cenário.

Use AskUserQuestion para determinar qual cenário se aplica:

P: Selecione o cenário de geração de PRD

Opção	Descrição
Iteração	Otimização iterativa com base em funcionalidades existentes
Nova Funcionalidade	Adicionar um novo módulo a um produto existente
Produto Novo (0-1)	Planejar um novo produto do zero

Coleta de Contexto por Cenário

Uma vez identificado o cenário, colete o contexto necessário:

Cenário	Informação Obrigatória	Método de Coleta
Iteração	1. Descrição da funcionalidade atual2. Estado da UI (captura de tela/HTML/link)3. Objetivo da iteração	Entrada do usuário + AskUserQuestion para opção de estado da UI
Nova Funcionalidade	1. Arquitetura geral do produto2. Guia de estilo (biblioteca de componentes/padrões de interação)3. Localização da entrada	Ler de `docs/product/` ou entrada do usuário
Produto Novo (0-1)	1. Contexto do produto e usuários-alvo2. Restrições de recursos3. Produtos de referência	Entrada do usuário + análise competitiva

Coleta de Estado da UI para Iterações: Quando o usuário selecionar "Iteração", pergunte como ele deseja fornecer o estado atual da UI:

Captura de Tela - O usuário fornece uma captura de tela; use mcp__zai-mcp-server__ui_to_artifact ou mcp__4_5v_mcp__analyze_image
Arquivo HTML - O usuário fornece o caminho local do HTML; use a ferramenta Read para analisar a estrutura DOM
Link Online - O usuário fornece uma URL; use mcp__web_reader__webReader (sem necessidade de login)

Etapa 0.5: Análise de Lacunas de Informação e Plano de PRD (CRÍTICO — GATE FORTE)

GATE FORTE: NÃO prossiga para a Verificação de Referências do Setor ou geração de PRD até que esta etapa esteja concluída e o usuário tenha aprovado o plano.

Protocolo de Pular Explicitamente (Se o usuário recusar explicitamente a interação): Se o usuário proibir explicitamente perguntas (por exemplo, "não pergunte mais, escreva logo"), você PODE pular os gates interativos — mas então você DEVE iniciar a saída com um bloco Declaração de Suposições listando cada suposição feita (cenário, capítulos selecionados/excluídos, produto alvo, valores padrão principais), para que o usuário possa corrigi-los. A Declaração de Suposições também serve como lista de verificação de completude da Disciplina de Evidências: informações não confirmadas são marcadas como 【待确认】, alegações sem evidências são marcadas como 【未验证】 (veja a Disciplina de Evidências abaixo), e não devem ser preenchidas com valores padrão inventados. Nunca pule silenciosamente.

Após a detecção do cenário e coleta de contexto:

Análise de Lacunas: Compare as informações fornecidas pelo usuário com os requisitos de contexto para este cenário. Liste cada campo obrigatório ausente. Verifique também docs/product/ para dados de percepção existentes (market-analysis.json, competitive-analysis, user-research.json, positioning.md).

Uma Pergunta de Cada Vez: Para cada item ausente, pergunte ao usuário usando AskUserQuestion com opções de múltipla escolha. NÃO agrupe várias perguntas em uma única mensagem.

Item Ausente	Exemplo de Pergunta
Captura de tela da UI	"Como você gostaria de fornecer o estado da interface atual?" → A. Já tenho captura de tela B. Tenho arquivo HTML C. Tenho link online D. Não tenho, pular por enquanto
Lista de concorrentes	"Quais concorrentes precisam ser analisados?" → multi-seleção + "Outro"
Usuário-alvo	"Quem é o usuário-alvo?" → A. Persona já definida B. Eu descrevo e você organiza C. Preciso fazer pesquisa de usuário primeiro
Produto de referência	"Tem algum produto de referência?" → A. Sim, vou descrever B. Você pesquisa benchmarks do setor para mim C. Não precisa de referência

Lidar com Ativos Ausentes: Se o usuário disser "Fornecerei capturas de tela depois" ou "pular", registre quais itens estão pendentes e anote-os no plano de PRD como [待补充].

Gerar Plano de PRD: Prepare (mas ainda não exiba) a estrutura do Plano de PRD. A tabela abaixo mostra o modelo com seleções padrão:

### Capítulos de PRD previstos para geração
| Capítulo | Resumo do Conteúdo | Selecionado | Status da Dependência |
|:---------|:-------------------|:------------|:----------------------|
| Cap. 0 Análise Comparativa do Setor | Pesquisará X produtos de referência | ✅ | Concluído / [待补充] |
| Cap. 1 Visão Geral do Projeto | Expandido a partir da descrição do usuário | ✅ | Concluído |
| Cap. 2 Análise de Negócios | Usuário-alvo X, Pontos problemáticos Y | ✅ | Concluído / [待补充] |
| Cap. 3 Requisitos Funcionais | [Lista de funcionalidades principais] | ✅ | Concluído |
| Cap. 4 Requisitos Não Funcionais | Padrões da indústria | ✅ | Gerado automaticamente |
| Cap. 5 Fluxo de Experiência do Usuário | Derivado das funcionalidades | ✅ | Precisa de UI complementar |
| Cap. 6 Riscos do Projeto | Com base na complexidade da funcionalidade | ✅ | Gerado automaticamente |
| Cap. 7 Recomendações de Conformidade | Com base no tipo de dados | ❌ | Gerado automaticamente |
| Cap. 8 Design de Protótipo | [Link do protótipo] | ❌ | - |
| Cap. 9 Métricas de Sucesso | Derivado dos objetivos | ❌ | Gerado automaticamente |

### Lista de Exclusão (NÃO gerar o seguinte)
- Plano técnico / Design de arquitetura — PRD é um documento de requisitos de produto, não inclui detalhes de implementação técnica
- Definições de API / Especificações de endpoint — A equipe de desenvolvimento escreverá separadamente no plano técnico
- Design de estrutura de tabela de banco de dados — Não está no escopo dos requisitos do produto

Nota: A tabela acima usa seleções padrão. Os valores reais de 「Selecionado」 serão preenchidos na Etapa 4.5 com base nas respostas do usuário sobre a seleção de capítulos. Ainda NÃO apresente esta tabela ao usuário.

4.5. Seleção de Capítulos (GATE FORTE — Antes de apresentar o Plano de PRD):

Apresente a seleção de capítulos ao usuário via AskUserQuestion com multiSelect. Devido ao limite de 4 opções, divida em 3 perguntas sequenciais. Construa as listas selected_chapters e excluded_chapters a partir das respostas e atualize a coluna 「Selecionado」 da tabela do Plano de PRD de acordo.

Pergunta 1 — Capítulos Principais (Cap. 0-3):

Opção	Padrão	Descrição
Cap. 0 Análise Comparativa do Setor	✅ Selecionado	Pesquisar produtos de referência e melhores práticas
Cap. 1 Visão Geral do Projeto	✅ Selecionado	Contexto, objetivos e escopo do projeto
Cap. 2 Análise de Negócios	✅ Selecionado	Usuários-alvo, pontos problemáticos, análise de mercado
Cap. 3 Requisitos Funcionais	✅ Selecionado	Lista de funcionalidades, histórias de usuário, requisitos detalhados

Pergunta 2 — Capítulos Estendidos (Cap. 4-7):

Opção	Padrão	Descrição
Cap. 4 Requisitos Não Funcionais	✅ Selecionado	Desempenho, segurança, disponibilidade, compatibilidade
Cap. 5 Fluxo de Experiência do Usuário	✅ Selecionado	Jornada do usuário, diagramas de fluxo de página
Cap. 6 Riscos do Projeto	✅ Selecionado	Riscos do projeto e estratégias de mitigação
Cap. 7 Recomendações de Conformidade	⬜ Não selecionado	Diretrizes de conformidade e categorias de risco

Pergunta 3 — Capítulos Opcionais (Cap. 8-9):

Opção	Padrão	Descrição
Cap. 8 Design de Protótipo	⬜ Não selecionado	Links de protótipo e notas de design
Cap. 9 Métricas de Sucesso	⬜ Não selecionado	Métricas de estrela do norte, processo e resultado

Exclusões Permanentes (não na lista de seleção, NUNCA gerados):

Plano técnico / Design de arquitetura — PRD não inclui detalhes de implementação técnica
Definições de API / Especificações de endpoint — Documentos de interface são escritos separadamente pela equipe de desenvolvimento
Design de estrutura de tabela de banco de dados — Não está no escopo dos requisitos do produto

Após coletar as seleções: Atualize a coluna 「Selecionado」 da tabela do Plano de PRD para refletir as escolhas do usuário (✅ para selecionado, ❌ para excluído).

Aprovação do Usuário: Use AskUserQuestion para apresentar o Plano de PRD (com seleções de capítulos) e obter aprovação explícita:

Opção	Descrição
Confirmar, gerar PRD com este plano de capítulos	Ir para Etapa 1 (Benchmarks do Setor) e Etapa 2 (Geração de PRD)
Ajustar seleção de capítulos	Reeleger os capítulos a serem gerados
Precisa ajustar o plano	Modificar o Plano de PRD e confirmar novamente
Tenho mais informações para adicionar	Voltar à Etapa 0.5 para complementar informações e regenerar o plano
Primeiro, complementar dados de percepção	Chamar market-research / competitive-analysis

Anti-Padrão: "Já tenho informações suficientes, deixe-me apenas gerar" — proibido. Mesmo com poucas lacunas, apresente o plano e obtenha aprovação.

Guia de Processamento de Imagens em Ambiente TUI

Em ambiente de terminal (TUI), o usuário pode fornecer imagens das seguintes maneiras:

Método 1: Caminho de Arquivo Local (Mais Simples)

Forneça diretamente o caminho local da imagem e use a ferramenta Read para ler:

# Exemplo de diálogo do usuário
"Analise esta captura de tela da UI: /Users/fh/Desktop/screenshot.png"
"Interface atual: ~/Screenshots/ui-2025-03-12.png"
"Imagem de referência: ./docs/product/images/reference.png"

Formatos de Caminho Suportados:

Caminho absoluto: /Users/fh/Desktop/screenshot.png
Abreviação de diretório home: ~/Screenshots/ui.png
Caminho relativo: ./images/ui.png

Formatos de Imagem Suportados: PNG, JPG, JPEG, WebP, GIF

Método 2: URL de Imagem Online

O usuário faz upload da imagem para um serviço de hospedagem/armazenamento em nuvem e fornece a URL:

# Exemplo de diálogo do usuário
"Captura de tela da UI: https://i.imgur.com/xyz.png"
"Imagem de referência: https://s3.aws.com/bucket/screenshot.png"

Use a ferramenta mcp__4_5v_mcp__analyze_image ou mcp__zai-mcp-server__ui_to_artifact para ler imagens remotas.

Serviços de Hospedagem Recomendados:

imgur.com (gratuito, sem necessidade de registro)
GitHub (como anexo de issue)
Armazenamento em nuvem (AWS S3, Alibaba Cloud OSS)

Método 3: Comando de Captura de Tela no Terminal

Oriente o usuário a usar ferramentas de captura de tela do terminal para gerar capturas rapidamente:

macOS:

# Capturar área selecionada (interativo)
screencapture -i ~/screenshot.png

# Capturar janela inteira
screencapture -w ~/screenshot.png

# Capturar tela inteira
screencapture ~/screenshot.png

Linux:

# ImageMagick (precisa instalar: sudo apt install imagemagick)
import ~/screenshot.png

# gnome-screenshot (Ubuntu/GNOME)
gnome-screenshot -a -f ~/screenshot.png

#spectacle (KDE)
spectacle -r -o ~/screenshot.png

Método 4: Obter Diretamente da Área de Transferência (macOS)

# Instalar ferramenta pngpaste
brew install pngpaste

# Salvar imagem da área de transferência como arquivo
pngpaste ~/screenshot.png

Fluxo de Processamento

Quando o usuário fornecer uma imagem:

Caminho Local → Usar ferramenta Read para ler diretamente
URL Remota → Usar mcp__4_5v_mcp__analyze_image ou mcp__zai-mcp-server__ui_to_artifact
Analisar Conteúdo da Imagem → Extrair estrutura da UI, layout, elementos interativos
Gerar PRD → Gerar documento de requisitos com base nos resultados da análise de imagem

Verificação de Referências do Setor

Após a detecção do cenário, coleta de contexto e esclarecimento das informações:

Referências fornecidas pelo usuário (prioridade): Produtos de referência especificados pelo usuário
Pesquisa suplementar do agente: Pesquisa automática de melhores práticas do setor com base em palavras-chave do cenário
Extrair melhores práticas: 3-5 padrões de interação/designs de funcionalidades de referência
Citar no PRD: Referenciar soluções de referência com justificativa para adoção/diferenciação

Mapeamento de Palavras-chave de Pesquisa:

Cenário	Palavras-chave de Pesquisa
Iteração	"{nome da funcionalidade} melhores práticas", "design da indústria {nome da funcionalidade}"
Nova Funcionalidade	"{tipo de produto} solução {nome do módulo}", "funcionalidade {funcionalidade} em produtos similares"
Produto Novo (0-1)	"framework de produto {setor}", "mapa de produto {domínio}"

Como Funciona

O processo de geração garante PRDs completos e acionáveis:

Detecção de Cenário - Use AskUserQuestion para identificar iteração/nova funcionalidade/novo produto
Coleta de Contexto - Reúna as informações necessárias com base no tipo de cenário
Análise de Lacunas de Informação - Identifique informações ausentes, faça uma pergunta de cada vez
Seleção de Capítulos - O usuário seleciona quais capítulos do PRD gerar (multiSelect)
Apresentação do Plano de PRD - Apresente o plano com as seleções de capítulos para aprovação do usuário (GATE FORTE)
Pesquisa de Referências do Setor - Pesquise e extraia melhores práticas (especificadas pelo usuário + pesquisa do agente)
Analisar requisitos - Estruture a solicitação de funcionalidade do usuário em componentes principais
Reunir contexto - Leia análise de mercado, insights competitivos, pesquisa de usuário
Montar seções - Construa APENAS as seções de PRD SELECIONADAS com o detalhamento adequado
Verificar completude - Verifique em relação aos padrões de qualidade (apenas capítulos selecionados)
Auto-revisão pré-entrega - Execute a verificação de portão traseiro do PRD (auto-verificação de capítulo + desafio de perspectiva do stakeholder); corrija bloqueadores ou marque como【待确认】
Gerar saída - Escrever em docs/product/prd/{nome-da-funcionalidade}-{data}-v{versão}.md (incluindo seção de「Registro de Pré-revisão」no final)

Restrições de Conteúdo (REGRAS FORTES):

Antes de gerar o conteúdo do PRD, observe:

Gere APENAS os capítulos selecionados pelo usuário. Pule os capítulos não selecionados completamente.
NUNCA gere os seguintes tipos de conteúdo, independentemente da entrada do usuário:
- Arquitetura técnica / detalhes de implementação
- Definições de endpoint de API / especificações
- Esquema de banco de dados ou designs de tabela
Se a descrição da funcionalidade do usuário mencionar detalhes técnicos, resuma-os como requisitos funcionais SEM expor detalhes específicos de implementação.

Parâmetros de Entrada

Parâmetro	Tipo	Obrigatório	Descrição
`requirements`	string	Sim	Descrição da funcionalidade ou história de usuário a ser documentada
`target_audience`	string	Não	Segmento de usuário-alvo ou persona
`context_refs`	list	Não	Arquivos de contexto relacionados a serem referenciados

Disciplina de Evidências

Marcação de Informação Ausente 【待确认】：Qualquer informação que não possa ser obtida a partir da entrada ou contexto deve ser marcada como 【待确认】; não invente valores padrão.
Rastreabilidade de Evidências 【未验证】：Afirmações sobre requisitos do usuário/mercado devem ser questionadas quanto à fonte da evidência; aquelas sem evidência devem ser marcadas como 【未验证】, indicando o método de verificação necessário.
Gate de Verificação de Completude：Antes da entrega formal, produza uma lista de verificação de completude das informações (Concluído ✅ / Pendente ⚠️ / Não Verificado ❓). Só gere o conteúdo principal após confirmação do usuário.

Relação com o Protocolo de Pular Explicitamente (Etapa 0.5): A Disciplina de Evidências é uma disciplina de saída (marcação de informações e auto-verificação pré-entrega); o Pular Explicitamente é uma disciplina de interação (tratamento de degração quando o usuário recusa explicitamente a interação). Elas são complementares e não conflitantes. No cenário de Pular Explicitamente, a lista de verificação de completude não é dispensada — ela é mesclada com a「Declaração de Suposições」, mas não aguarda mais a confirmação do usuário; as informações não confirmadas na declaração de suposições também devem ser marcadas como 【待确认】 / 【未验证】 de acordo com as regras desta seção.

Estrutura de Saída

O PRD segue esta estrutura (alinhada com o modelo padrão de PRD). IMPORTANTE: Este modelo mostra todos os capítulos possíveis. Gere APENAS os capítulos selecionados pelo usuário. Pule os capítulos não selecionados completamente. Não gere arquitetura técnica, especificações de API ou designs de banco de dados em nenhuma circunstância.

# [Nome da Funcionalidade] PRD

## Informações Básicas do Documento
- **Versão do Documento**: v1.0
- **Data de Criação**: YYYY-MM-DD
- **Última Atualização**: YYYY-MM-DD
- **Status do Documento**: Rascunho/Revisão/Aprovado
- **Criado por**: [Nome do usuário]
- **Revisor**: [Pendente]

## Histórico de Revisões
| Versão | Data | Conteúdo da Revisão | Revisor |
|:-------|:-----|:--------------------|:--------|
| v1.0 | YYYY-MM-DD | Versão inicial | [Criador] |

## 0. Análise Comparativa do Setor
### 0.1 Produtos de Referência
| Produto | Funcionalidade Principal | Adoção/Diferenciação |
|:--------|:-------------------------|:---------------------|
| [Concorrente A] | XXX | Adotar o padrão XXX porque... |
| [Concorrente B] | XXX | O ponto de diferenciação é... |

### 0.2 Resumo das Melhores Práticas
- **Padrão de Interação**: [Padrão de interação da indústria adotado]
- **Diferenciação Principal**: [Aspecto único desta solução]

## 1. Visão Geral do Projeto
### 1.1 Contexto do Projeto
[Contexto de mercado, contexto competitivo, contexto de necessidade do usuário]

### 1.2 Objetivos do Projeto
#### 1.2.1 Objetivos Principais
- [Objetivo principal quantificável]

#### 1.2.2 Objetivos Secundários
- [Objetivos de suporte]

### 1.3 Escopo do Projeto
#### 1.3.1 Escopo Incluído
- [Conteúdo incluído nesta iteração/funcionalidade]

#### 1.3.2 Escopo Não Incluído
- [Itens explicitamente fora do escopo desta iteração]

## 2. Análise de Negócios
### 2.1 Usuários-Alvo
| Função do Usuário | Descrição | Necessidade Principal |
|:------------------|:----------|:----------------------|
| Usuário A | [Da pesquisa de usuário] | XXX |
| Usuário B | [Da pesquisa de usuário] | XXX |

### 2.2 Pontos Problemáticos do Usuário
| ID do Ponto | Descrição do Ponto Problemático | Nível de Impacto |
|:------------|:--------------------------------|:------------------|
| P-001 | XXX | Alto/Médio/Baixo |
| P-002 | XXX | Alto/Médio/Baixo |

### 2.3 Análise de Mercado
[Tendências do setor, cenário competitivo, oportunidades de mercado]

## 3. Requisitos Funcionais
### 3.1 Lista de Funcionalidades Principais
| ID da Func. | Nome da Funcionalidade | Prioridade | Descrição |
|:------------|:-----------------------|:-----------|:-----------|
| F-001 | XXX | P0/P1/P2 | XXX |
| F-002 | XXX | P0/P1/P2 | XXX |

### 3.2 Histórias de Usuário
#### US-1: [Nome da Funcionalidade]
**Como** [Função do Usuário]
**Eu quero** [Descrição da Funcionalidade]
**Para que** [Valor de Negócio]

**Critérios de Aceitação**:
- Dado [Pré-condição]
- Quando [Ação executada]
- Então [Resultado esperado]

**Prioridade**: P0/P1/P2
**Estimativa**: X Story Points

#### US-2: [Nome da Funcionalidade]
...

### 3.3 Detalhes da Funcionalidade
#### F-001: [Nome da Funcionalidade]
**Descrição**: [Descrição detalhada da funcionalidade]

**Fluxo de Interação**:
1. Passo um
2. Passo dois
3. Passo três

**Casos de Borda**:
- Fluxo normal: ...
- Caso excepcional: ...

## 4. Requisitos Não Funcionais
### 4.1 Requisitos de Desempenho
- Tempo de resposta da página < XXXms
- Suportar XXX usuários simultâneos
### 4.2 Requisitos de Segurança
- Armazenamento de dados criptografado
- Controle de permissão do usuário
### 4.3 Requisitos de Disponibilidade
- Disponibilidade do sistema > 99.9%
### 4.4 Requisitos de Compatibilidade
- iOS 14+, Android 10+
- Compatibilidade com navegadores principais

## 5. Fluxo de Experiência do Usuário
### 5.1 Jornada do Usuário
[Descrição do caminho principal do usuário]
1. Usuário entra → 2. Executa ação → 3. Atinge objetivo

### 5.2 Diagrama de Fluxo de Páginas
[Descrição das relações de navegação entre páginas]
- Página A → Página B → Página C

## 6. Riscos e Mitigações do Projeto
> Nota: Esta seção contém apenas riscos de produto/negócios, não riscos de implementação técnica (riscos técnicos são avaliados pela equipe de desenvolvimento no plano técnico)
| ID do Risco | Descrição do Risco | Probabilidade | Impacto | Ação de Mitigação |
|:------------|:-------------------|:--------------|:--------|:------------------|
| R-001 | XXX | Alta/Média/Baixa | Alto/Médio/Baixo | XXX |
| R-002 | XXX | Alta/Média/Baixa | Alto/Médio/Baixo | XXX |

## 7. Recomendações de Conformidade

### 7.1 Resumo dos Pontos de Conformidade
[Resumo dos principais pontos identificados pela revisão de especialistas em conformidade]

### 7.2 Avisos de Risco
| Categoria de Risco | Descrição | Recomendação |
|:-------------------|:-----------|:--------------|
| Privacidade | [Tratamento de dados do usuário] | [Recomendação de conformidade] |
| Conteúdo | [Pontos de revisão de conteúdo] | [Recomendação de conformidade] |
| Segurança de Dados | [Requisitos de armazenamento e transmissão de dados] | [Recomendação de conformidade] |
| Terceiros | [Conformidade de serviços de terceiros dependentes] | [Recomendação de conformidade] |

### 7.3 Anexos do Relatório de Conformidade
- [ ] Relatório de análise de conformidade anexado (se houver, fornecer caminho)
- [ ] Aguardando revisão de conformidade (se necessário, agendar avaliação de especialista em conformidade)

...

[truncado para tradução]

kelegele/oh-my-pm

O que é oh-my-pm?

Perguntar na sua IA favorita

Documentação