linsaber1012-coder/pm-prd-to-demo

PM · PRD → Demo Fluxo de Trabalho Integrado

Leve uma "ideia de produto" por todo o ciclo "alinhamento → documentação → protótipo clicável", gerando um PRD pronto para desenvolvimento, definições de métricas implementáveis de forma independente, e um protótipo compartilhável que reutiliza a interface real do repositório base. Este fluxo de trabalho é independente de plataforma (funciona com Claude Code / Codex / Cursor / Gemini); instruções de portabilidade estão na seção "Adaptação de Plataforma".

Quando usar

• Quando o usuário atua como gerente de produto e precisa produzir entregáveis como PRD / definição de métricas / protótipo interativo;
• Geralmente quando há um repositório ou sistema existente para melhorar, que precisa reutilizar sua estrutura real;
• Quando se deseja simultaneamente um protótipo preliminar, clicável e compartilhável para auxiliar na revisão.

Não aplicável a: tarefas puramente de implementação de código, alteração de apenas algumas linhas, ou trabalhos sem qualquer componente de decisão de produto.

O que será gerado

1. PRD.md — fonte única da verdade (o que fazer / para quem / escopo / riscos / descrição detalhada de páginas e interações).
2. Definição de Métricas.md — documento de especificações completamente autossuficiente; o desenvolvimento pode implementar cada métrica/regra apenas com ele.
3. Protótipo HTML autossuficiente e compartilhável — esquerda = interface alvo (reutilizando a UI real do repositório base + suas alterações, dados mock obrigatoriamente marcados), direita = painel completo do PRD.

---

Disciplina obrigatória nas três fases (intransigível)

1. Zero invenção, tudo fundamentado em evidência: especificações devem referenciar código-fonte / documentação oficial / confirmação do usuário; se não for encontrado, declare explicitamente, não invente; dados mock devem ser explicitamente marcados.
2. Zero emoji: documentos e protótipo não devem usar emoji / ícones de estado; estados devem ser descritos com texto (preservado / atualizado / novo / não testado / a verificar, etc.).
3. Escrita → Revisão adversarial em ciclo fechado: qualquer documento entregável deve ser escrito, depois revisado por um "PM sênior rigoroso" (seguindo prompt em prompts/reviewer-agent.md), e revisado conforme os problemas encontrados até aprovação.
4. Consistência entre artefatos: PRD ↔ Definição de Métricas ↔ Protótipo devem ter especificações consistentes; itens órfãos ou contraditórios devem ser corrigidos imediatamente.
5. Adaptar ao estilo de interação do usuário: alguns preferem diálogo, outros preferem opções; se for rejeitado uma vez, mude a abordagem, não insista na mesma.
6. Não agir antes de decisões estarem definidas: antes de documentar, esclareça as decisões principais; se o objetivo não estiver claro, pare e discuta, não adivinhe.
7. Texto livre de artificialidade de IA (humanizado): o corpo do documento deve usar linguagem natural, direta, como se escrita por humano; evite traços típicos de IA (abuso de travessão, clichês como "não apenas X, mas também Y", paralelismos vazios / estruturas triplas, cautela excessiva, floreios exagerados, obviedades). Pode-se carregar o skill local humanizer ou consultar references/writing-style.md (que compila stop-slop / Humanizer-zh / blader-humanizer). Nota: especificações técnicas ainda devem ser precisas — humanizar não significa sacrificar exatidão nem encher de palavras soltas.

---

Fase 0 · Descoberta interativa e definição de decisões

Objetivo: pesquisar e esclarecer as ideias, necessidades e restrições reais do usuário, definindo as decisões principais — esta etapa é interativa entre IA e humano; a IA não decide pelo usuário.

1. Levante ativos existentes: leia a estrutura real do repositório / documento / sistema antigo fornecido pelo usuário (se a plataforma suportar exploração paralela, faça-o; caso contrário, leia um por um). Entenda o que ele realmente faz e o que pode ser reutilizado.
2. Esclareça requisitos interativamente: use perguntas e respostas para ajudar o usuário a convergir ideias vagas em decisões claras — decisões típicas a definir: qual repositório base usar, escopo in/out, métricas/funcionalidades desejadas, arquitetura de informação, não-objetivos explícitos. Faça algumas perguntas-chave de cada vez, sem bombardear o usuário.
3. Produza registro de decisões: documente as decisões definidas em um arquivo curto de "decisão/planejamento", que servirá como entrada para a Fase 1.

Critério de saída: cada decisão principal tem uma resposta clara, aprovada pelo usuário.

Fase 1 · Produzir PRD + Definição de Métricas

Objetivo: gerar dois documentos prontos para desenvolvimento.

1. Consulte o template: use references/prd-checklist.md (lista completa orientada à prática nacional + adaptação por tipo de projeto) para determinar quais seções produzir e quais pular.
2. Escreva: siga prompts/writer-agent.md para redigir o PRD e a Definição de Métricas. Pontos-chave:
   • PRD deve cobrir: contexto/objetivos/métrica de sucesso/escopo/riscos/estrutura funcional + arquitetura de informação + fluxogramas (use Mermaid)/descrição detalhada da exibição e interação de cada página (em nível de campo)/glossário/regras globais/partes interessadas.
   • Definição de Métricas completamente autossuficiente: especificações devem estar totalmente inline; não escreva "veja outro documento"; o desenvolvimento deve conseguir implementar apenas com este documento.
3. Revise: use o persona "PM sênior" de prompts/reviewer-agent.md para revisão adversarial (completeza / executabilidade / especificações consistentes com código-fonte / escopo e não-objetivos / riscos / zero emoji / sem links quebrados / consistência entre documentos).
4. Ciclo de revisão: corrija itens obrigatórios apontados na revisão; re-revise até aprovação.
5. Passe pelo checklist: antes de entregar, verifique cada item de references/pitfalls.md (checklist acumulado de erros passados).

Fase 2 · Gerar protótipo compartilhável

Objetivo: um protótipo clicável com esquerda = interface alvo, direita = PRD completo; design fiel à fonte definida (referência / repositório base / concorrente, veja abaixo). Regras rígidas em references/prototype-guardrails.md.

1. Determine a fonte de design (por prioridade):
   • ① O usuário forneceu um protótipo de referência / design → Use-o como base, reproduza fielmente sua aparência e layout;
   • ② Melhoria em um repositório base existente → Clone/leia seu front-end, extraia tokens de design reais e layout (esquema de cores / claro-escuro / barra lateral ou superior / cards / campos reais e colunas de tabela das visualizações), copie sem improvisar;
   • ③ Nenhum dos acima → A IA constrói por conta própria, escolhendo páginas de produtos similares / concorrentes como referência para criar, e explique no protótipo qual referência foi usada e por quê.
2. Crie HTML autossuficiente: arquivo único, esquerda = interface alvo (fidelidade ao repositório base + suas alterações, dados mock obrigatoriamente marcados), direita = painel completo do PRD (use um renderizador markdown minimalista para inline do PRD).
3. Autossuficiente / Seguro CSP: todo CSS/JS inline, sem referência a CDN/fontes/ícones externos; itens que não podem ser renderizados ao vivo (como certas bibliotecas de ícones) devem ser honestamente marcados como limitados, com fallback para representação legível.
4. Publique e itere: publique em um link compartilhável; quando o usuário sugerir alterações, atualize tanto o protótipo quanto o PRD simultaneamente, mantendo consistência, e republicue no mesmo link.

---

Checklist pré-entrega (resumo, detalhes em references/pitfalls.md)

• Zero emoji (incluindo em gráficos / labels de nós dentro de blocos de código)
• Nada inventado: números/especificações com origem rastreável; dados mock marcados
• Definição de Métricas autossuficiente, sem links para "veja outro documento"
• Especificações consistentes entre artefatos, sem itens órfãos / contraditórios
• Design do protótipo fiel à fonte definida (referência fornecida → reproduzir; repositório base → copiar tokens; nada → referenciar concorrente e explicar), não improvisado
• Compostos / totais com fórmulas e composição explícitas
• Itens não renderizáveis / não testados / desconhecidos marcados honestamente, não falsificados

---

Adaptação de Plataforma (Portabilidade)

O corpo deste SKILL.md contém instruções em linguagem natural independentes de plataforma; qualquer LLM pode segui-las. Três diferenças são resolvidas fora do corpo:

• Carregamento/Ativação: modo de instalação e invocação para cada plataforma em README.md (Claude Code: colocar no diretório de skills; Codex: via referência em skills/AGENTS.md; Cursor/Gemini: caminhos próprios).
• Degradação de capacidade: onde se menciona "enviar sub-agente para revisão/exploração", se a plataforma atual não oferece suporte a sub-agentes, você mesmo realiza a mesma revisão/exploração, sem alterar a disciplina.
• Ferramentas independentes: o corpo descreve apenas ações (pesquisar na web, ler repositório, escrever arquivo, publicar protótipo), sem vincular a nomes específicos de ferramentas; cada plataforma mapeia para suas próprias ferramentas.

Recursos Acompanhantes

• references/prd-checklist.md — Lista de componentes de PRD + adaptação por tipo de projeto
• references/prototype-guardrails.md — Regras rígidas para protótipo
• references/pitfalls.md — Checklist de armadilhas
• references/writing-style.md — Regras de escrita humanizada / anti-IA (compilação de stop-slop / Humanizer-zh / blader-humanizer + skill local humanizer)
• prompts/writer-agent.md — Template de prompt para agente redator
• prompts/reviewer-agent.md — Persona de PM sênior + itens de verificação para revisão adversarial
• templates/prd-skeleton.md / templates/metric-spec-skeleton.md — Esqueletos de template