plataforma-PRD-construtor

Construtor de PRD de Plataforma

Use esta skill para converter entradas brutas em requisitos de produto estruturados e prontos para implementação. Não traduza simplesmente. Entenda, reorganize, enriqueça e preserve o escopo preciso.

Modos de Operação

Escolha o modo mais leve que atenda à solicitação:

• Construção de PRD completo: crie um PRD completo para um requisito complexo ou entre sistemas.
• Construção de seção: escreva apenas as seções solicitadas, como contexto, escopo, fluxo, alterações de API/dados ou rollout.
• Reescrita / polimento: melhore estrutura, clareza, inglês ou redação bilíngue sem alterar decisões.
• Normalização de entrada: converta anotações dispersas em decisões confirmadas, suposições, decisões ausentes e linguagem legível por engenharia antes de redigir.
• Ajuste de template: escolha o tipo de artefato certo quando a solicitação não for necessariamente um PRD completo.
• Rascunho de alinhamento de direção: crie um conceito leve / versão de alinhamento antes de expandir para um PRD completo.

Primeira Ação

Identifique brevemente:

• cenário de negócio
• capacidade da plataforma
• sistemas envolvidos
• fase atual e exclusões
• tipo de artefato: PRD completo, seção de PRD, BRD de uma página, rascunho bilíngue, reescrita em inglês, tabela ou descrição de fluxo

Se o usuário estiver apenas perguntando sobre impacto ou viabilidade, não redija o PRD ainda; use a análise de impacto primeiro.

Se o tipo de artefato não estiver claro, proponha o menor artefato útil e continue, a menos que essa escolha crie risco de entrega.

Etapa 0: Detecção de Estágio

Antes de redigir, classifique o estágio do usuário:

• Apenas ideia: crie um rascunho de alinhamento de direção primeiro.
• Anotações dispersas: normalize decisões, suposições e decisões ausentes primeiro.
• Escopo não resolvido: encaminhe para platform-scope-checker antes de redigir os requisitos da fase atual.
• Pronto para redigir: construa o PRD ou seção solicitada.
• Rascunho existente: melhore a estrutura ou encaminhe para platform-prd-reviewer se o usuário quiser feedback.
• Solicitação de detalhes de RFC: mantenha a semântica de produto no PRD e encaminhe especificidades de implementação para acompanhamento de engenharia.

Portão de Desafio de Construção

Antes de transformar uma solicitação em um PRD pesado, desafie brevemente se o mesmo objetivo de negócio pode ser alcançado por:

• capacidade existente da plataforma
• configuração
• processo operacional ou tratamento manual temporário
• mudança de fluxo de trabalho menor
• rollout em fases
• placeholder de compatibilidade sem o comportamento completo da fase atual

Se a resposta não estiver clara ou o risco de construção for alto, recomende uma verificação de escopo antes de escrever um PRD completo.

Entrega em Duas Fases

Para requisitos ambíguos, do zero ou grandes entre sistemas, prefira duas fases:

1. Rascunho de Alinhamento de Direção: problema, usuários/operações alvo, capacidade da plataforma, limite de escopo, fluxo principal, propriedade, suposições e decisões em aberto.
2. PRD Detalhado: requisitos por sistema, alterações de campo/API/dados, estados/casos de borda, rollout/operações, critérios de aceitação e riscos.

Não pule para o PRD detalhado quando a direção central do produto, o limite do MVP ou a fonte da verdade ainda não estiverem resolvidos.

QUANDO NÃO USAR

Não use esta skill como primeira ação quando:

• o problema de negócio ou o usuário alvo ainda estiver em contestação; primeiro esclareça a direção com platform-product-guide
• a pergunta for "devemos fazer isso agora?"; primeiro use platform-scope-checker
• o usuário quiser apenas feedback de revisão em um artefato existente; use platform-prd-reviewer
• a solicitação for uma RFC de engenharia pura, design de código ou plano de implementação sem trabalho de requisito de produto

Normalizador de Entrada do PM

Quando a entrada for vaga, não técnica ou escrita como anotações dispersas, primeiro traduza-a em decisões de produto legíveis por engenharia antes de redigir. Não exija que o usuário use vocabulário técnico.

Use esta saída leve quando decisões estiverem ausentes:

Decisões Conhecidas
- ...

Decisões Ausentes
- ...

Tradução Relevante para Engenharia
- "Precisa de registro de aprovação" significa que campos de log de auditoria, momento da escrita, acesso à consulta e retenção precisam de decisões.
- "Notificar outro sistema" significa que timing do callback, retry, timeout, tratamento de falha e consistência de status precisam de decisões.

Faça perguntas em linguagem de negócio em vez de perguntas com rótulos técnicos:

• Em vez de "Qual é a chave de idempotência?", pergunte "Se a mesma solicitação for enviada duas vezes, o sistema deve criar um novo registro, rejeitá-lo ou retornar o existente?"
• Em vez de "Qual é a estratégia de retry do callback?", pergunte "Se o sistema receptor não puder ser notificado, o que os usuários devem ver, quem corrige e por quanto tempo pode ficar sem solução?"
• Em vez de "Quem é a fonte da verdade?", pergunte "Se dois sistemas mostrarem status diferentes, qual deve ser confiável?"
• Em vez de "Qual é a estratégia de compatibilidade?", pergunte "Os registros existentes ou processos em andamento serão afetados após o lançamento?"
• Em vez de "Defina uma máquina de estados", pergunte "Quais status esta solicitação pode ter, desde a criação até a conclusão, e quais ações são permitidas em cada status?"

Livro Razão de Suposições e Evidências

Quando decisões importantes forem inferidas de anotações brutas, traga-as à tona antes de finalizar:

Suposições
- A1: ...

Evidência / Fonte
- E1: Da nota do usuário / protótipo / PRD anterior / nota de reunião / instrução explícita

Precisa de Confirmação
- C1: ...

Não transforme silenciosamente suposições em requisitos. Se o usuário pedir para prosseguir, mantenha itens não resolvidos em Perguntas em Aberto com proprietário/dependência quando conhecido.

Seleção de Template

Escolha o template pelo tipo de artefato em vez de forçar uma estrutura pesada.

PRD de funcionalidade curta:

• Contexto
• Objetivo
• Escopo
• Requisitos
• Alterações de API / Dados
• Casos de Borda
• Anexo / Links

Nota de alteração de API / campo:

• Contexto
• Contrato Alterado
• Tabela de Campos
• Comportamento de Validação / Padrão
• Compatibilidade Retroativa
• Consumidores a Jusante
• Exemplos

PRD de UI de configuração:

• Contexto
• Objetivo
• Caminho da Página / Entrada
• Campos da Lista
• Comportamento de Filtro / Consulta
• Comportamento de Criar / Editar
• Regras de Validação
• Permissão / Auditoria
• Anexo / Protótipo

PRD de migração:

• Contexto
• Escopo
• Sistemas de Origem / Destino
• Fluxo de Migração
• Mapeamento de Dados
• Checklist de Validação / Reconciliação
• Cutover / Rollback
• Perguntas em Aberto

PRD de lógica de fórmula / regra:

• Contexto
• Formato da Regra
• Definições de Campo
• Lógica de Processamento
• Exemplos
• Casos de Borda
• Compatibilidade Retroativa

Estrutura Padrão de PRD

Use esta estrutura a menos que o usuário forneça um template diferente:

1. Contexto
2. Objetivo
3. Escopo
4. Atores / Sistemas
5. Fluxo Geral
6. Detalhes do Fluxo
7. Requisitos por Sistema
8. Alterações de API / Dados
9. Cenários e Casos de Borda
10. Rollout / Operações
11. Perguntas em Aberto
12. Dependências / Riscos

Para seções curtas, mantenha apenas os cabeçalhos relevantes, mas preserve a mesma ordem de pensamento.

Use o Modelador de Fluxo da Plataforma Quando

Use platform-flow-modeler antes de escrever as seções Fluxo Geral, Detalhes do Fluxo, Cenários e Casos de Borda, Transição de Estado ou Operações quando o requisito envolver 3+ sistemas, mudanças de ciclo de vida/status, callback/retry/timeout, rollback/cancelar/reenviar, reconciliação, liquidação, migração ou fallback manual.

Deixe-o moldar as tabelas de fluxo primeiro, depois converta essas tabelas em texto de PRD, requisitos por sistema, cenários, critérios de aceitação e perguntas em aberto.

Contrato de Saída

Todo artefato no estilo PRD deve tornar estas coisas testáveis:

• Problema e "por que agora"
• Objetivo da fase atual
• Limites do escopo
• Fluxo principal e exceções principais
• Decisões de produto ainda em aberto
• Critérios de aceitação ou matriz de cenários
• Proprietário/fonte da verdade para comportamento entre sistemas
• Rollout, rollback ou tratamento manual temporário quando relevante

Forma padrão de resposta:

1. Breve nota sobre o tipo de artefato selecionado, quando útil
2. Conteúdo do PRD redigido ou seção solicitada
3. Suposições e decisões em aberto, se houver
4. Próxima rota de revisão sugerida: verificação de escopo, revisão de PRD, acompanhamento de RFC ou confirmação de stakeholder

Esta skill deve produzir um artefato, não apenas conselhos. Se o artefato não puder ser produzido com segurança, produza o livro razão de decisões ausentes e a próxima ação.

Para templates detalhados de PRD e contratos de saída específicos de artefato, leia references/prd-output-contract.md quando a tarefa envolver um PRD completo, PRD de plataforma do zero, PRD de migração, PRD de UI de configuração ou nota de alteração de API/dados.

Cenários e Critérios de Aceitação

Para as seções Cenários e Casos de Borda, use critérios de aceitação no formato Dado/Quando/Então quando melhorar o alinhamento entre QA e engenharia:

**Cenário: [nome]**
- Dado: [pré-condição: estado do sistema, ator, dados, configuração]
- Quando: [ação de gatilho]
- Então: [resultado esperado: status final, resultado visível para usuário/operações, sincronização a jusante, registro de auditoria]

Cubra estes tipos de cenário quando relevante:

• Caminho feliz
• Falha de validação: campo ausente, valor inválido, submissão duplicada
• Falha do sistema a jusante: timeout de callback, erro de API, falha parcial
• Submissão concorrente ou duplicada
• Caso de borda de transição de status: reenvio a partir de estado terminal, cancelamento no meio do fluxo
• Rollback ou reversão
• Fallback manual: intervenção de operações ou entrada na fila de exceção
• Limite de permissão: ator não autorizado ou incompatibilidade de sistema de origem

Faça cada cláusula Então testável. Nomeie o status final, o resultado visível para o usuário/operações, se os sistemas a jusante são notificados e se um registro de auditoria/evento é criado.

Se a matriz de cenários for grande, use uma tabela compacta:

Cenário	Pré-condição	Gatilho	Status Final	Resultado Usuário/Ops	A Jusante	Auditoria

Estilo de Tabela de API / Dados

Para alterações de API ou dados, prefira tabelas com:

• Campo
• Tipo de Dados / Tipo
• Obrigatório
• Valor / Validação
• Descrição
• Exemplo
• Tipo de Alteração: novo / existente / removido, quando relevante
• Proprietário / Consumidor, quando a propriedade importa

Adições para PRD de Plataforma do Zero

Para novas capacidades de plataforma/infraestrutura, adicione:

• direção da plataforma e princípios de design
• objetos de configuração vs objetos de runtime
• tabela de propriedade/fonte da verdade
• ciclo de vida/máquina de estados
• comportamento de versionamento e snapshot
• comportamento de callback, retry, timeout e idempotência
• log de auditoria/eventos
• isolamento de permissão e sistema de origem
• exclusões do MVP e iteração futura
• modelo de UI/workspace por função, escopo de dados e região operacional

Regras de Escrita

• Converta notas brutas em inglês profissional quando a saída em inglês for solicitada.
• Preserve terminologia mista chinês/inglês quando ela refletir nomes reais de sistemas ou artefatos da equipe.
• Adicione explicações ausentes necessárias para que os leitores entendam e implementem, mas não invente decisões de negócio.
• Se a qualidade da entrada for irregular, normalize-a em camada de negócio e camada de colaboração de engenharia antes de escrever o PRD final.
• Use hierarquia numerada para capacidade de revisão.
• Use tabelas para campos, APIs, propriedade, cenários, cálculos, transições de status e perguntas em aberto.
• Separe requisitos por sistema quando múltiplos sistemas mudarem.
• Mantenha as seções legíveis para produto legíveis para produto; mova detalhes de baixo nível para seções de API/dados ou perguntas em aberto.
• Siga os protótipos fornecidos ou a estrutura de PRD existente quando o usuário disser para basear o trabalho neles.

Disciplina de Escopo

Sempre separe:

• No Escopo
• Fora do Escopo
• Não Suportado Nesta Fase
• Iteração Futura

Não inclua funcionalidades de fases futuras nos requisitos da fase atual, exceto como exclusões explícitas, notas de compatibilidade ou iteração futura.

Requisitos de Fluxo e Dados

Para trabalho entre sistemas:

• descreva fluxos de criação/consulta/callback/atualização/liquidação/reconciliação separadamente quando relevante
• identifique pontos de persistência e mudanças de status
• defina campos de tempo de configuração separadamente de campos de runtime
• distinga campos de snapshot de campos resolvidos dinamicamente
• use nomes de campo com cuidado; nomes no singular/plural podem codificar escopo, como portalCode vs portalCodes

Diretrizes

• Trate PRDs históricos como material de aprendizado/referência, a menos que o usuário peça para reescrevê-los.
• Não injete contexto não relacionado de projetos anteriores.
• Não produza código quando o usuário pedir requisitos.
• Não polir demais em linguagem de marketing.
• Não esconda decisões em aberto; liste-as claramente com proprietário/dependência quando conhecido.

Erros Comuns a Sinalizar

• Redigir requisitos detalhados antes que o alinhamento de direção esteja pronto.
• Transformar suposições em requisitos sem rotulá-las.
• Misturar o MVP atual com o comportamento de iteração futura.
• Escrever apenas comportamento de página/botão enquanto deixa estados, propriedade e tratamento de exceção implícitos.
• Prescrever excessivamente design de banco de dados, fila, trabalho de retry ou serviço no PRD.
• Tratar uma solicitação de implementação como pronta para produto sem verificar o objetivo de negócio e o limite do escopo.

Roteamento

• Encaminhe para platform-product-guide quando a direção de negócio, abstração da plataforma ou enquadramento da decisão não estiverem prontos.
• Encaminhe seções com muitos fluxos para platform-flow-modeler antes de convertê-las em conteúdo de PRD.
• Encaminhe para platform-scope-checker quando a inclusão da fase atual, o tamanho do MVP ou a complexidade oculta não estiverem resolvidos.
• Encaminhe para platform-prd-reviewer após redigir quando o usuário quiser prontidão, lacunas ou pontuação.
• Encaminhe perguntas de implementação no nível de RFC para acompanhamento de engenharia, mantendo a semântica de produto no PRD.

Checklist de Qualidade

Antes de finalizar, verifique:

• O documento explica o que construir e por quê.
• O escopo é explícito: no escopo, fora do escopo, não suportado agora, futuro.
• Os requisitos são testáveis o suficiente para QA ou revisão de engenharia.
• A propriedade entre sistemas e a fonte da verdade estão visíveis.
• As suposições estão separadas das decisões confirmadas.
• As considerações técnicas são apresentadas sem prescrever excessivamente a implementação.
• A próxima rota ou etapa de revisão é explícita.

Referências

• references/prd-output-contract.md: carregue quando um template detalhado, contrato específico de artefato ou checklist de qualidade for necessário.