AI PRD: escreva requisitos que um sistema modelo possa realmente cumprir
Um PRD para um sistema de IA é um documento diferente. Seus requisitos não são instruções para um engenheiro; são restrições para um sistema que improvisará. Este skill reestrutura o documento em torno desse fato.
Arquivos que este skill aciona
- ../../templates/definition/prd.md, o template base do PRD
- A sobreposição de IA em
templates/ai/: eval-spec.md, guardrails.md, hallucination-controls.md, human-approval-gates.md, prompt-structure.md, context-management.md, red-team-review.md, e para sistemas agentivos agent-architecture.md e multi-agent-workflow.md - Para contextos regulados: ../../modules/regulated/templates/regulated-ai-prd-template.md, guiado por ../../modules/regulated/SKILL.md
Quando usar
- Especificando qualquer recurso onde um LLM, agente ou modelo toma ou rascunha uma decisão
- Revisando um PRD existente que diz "o IA deve..." em algum lugar
- Transformando uma demo em algo pelo qual uma equipe de engenharia possa ser responsabilizada
As cinco seções que este skill impõe
1. Critérios de aceitação são conjuntos de avaliação, não frases
"O agente deve extrair o nome do comerciante" é um desejo. Um requisito é:
- Um conjunto de exemplos rotulados (mínimo de 30 a 50 casos para um primeiro lançamento)
- Um limite de aprovação declarado como um número (acurácia, recall em k ou pontuação do juiz)
- A regra para o que acontece abaixo do limite (bloquear lançamento, não "revisar")
Para cada "deve" no rascunho, pergunte: onde está o conjunto de exemplos, qual é o número, quem é responsável por adicionar casos de falha de volta ao conjunto. Capture as respostas em ../../templates/ai/eval-spec.md.
2. Casos extremos são a especificação, não o apêndice
O caminho feliz é o que o modelo faz de graça. O documento ganha seu valor nos limites. Exija tabelas explícitas para:
- DEVE RECUSAR: entradas que o sistema recusa (fora do escopo, inseguras, ambíguas além do reparo)
- DEVE ESCALAR: condições que encaminham para um humano, com o destino do encaminhamento nomeado; capture gatilhos e comportamento de timeout em ../../templates/ai/human-approval-gates.md
- NUNCA DEVE INVENTAR: campos onde a fabricação é pior que a ausência (números, nomes, declarações legais ou regulatórias, valores monetários); a política de abstenção reside em ../../templates/ai/hallucination-controls.md
3. Não determinismo é colocado por escrito
A mesma entrada pode produzir uma saída diferente amanhã. O PRD deve declarar:
- Quais variações de saída são aceitáveis (redação? ordenação? formatação?)
- Quais são defeitos (decisão diferente, número diferente, comportamento de recusa diferente)
- Postura de reprodutibilidade: política de temperatura e seed, e se os logs capturam o suficiente para reproduzir qualquer decisão
Se o PRD não disser isto, o QA decidirá depois, em um rastreador de bugs, com raiva.
4. Guardrails são recursos com proprietários
Cada guardrail ganha uma linha em ../../templates/ai/guardrails.md: nome, gatilho, comportamento, proprietário, teste. Conjunto mínimo a considerar para qualquer recurso agentivo:
- Falha fechada em saída não verificável (não pode verificar = não enviar ao usuário)
- Aprovação humana antes de qualquer coisa irreversível (envios, pagamentos, exclusões, postagens)
- Limites de gasto e taxa com um teto declarado e um comportamento declarado no teto
- Isolamento de entrada: o conteúdo que o sistema lê são dados, nunca instruções
- Trilha de auditoria: quem ou o que decidiu, com base em quais entradas, em qual versão do modelo
5. A página de operações
- Custo por chamada alvo e o limite de alerta
- Orçamento de latência por etapa
- Fixação da versão do modelo e o processo de decisão de atualização
- Telemetria: o que é registrado por decisão, onde as avaliações são executadas (CI, pré-lançamento, amostragem de produção) e o gatilho de reversão
Rota regulada
As ferramentas de PRD genérico escrevem as cinco seções acima e param. Quando o produto está sob um regulador financeiro ou de dados, não execute a sobreposição deste skill a partir da memória. Comece em vez disso pelo template exato em bytes em ../../modules/regulated/templates/regulated-ai-prd-template.md, siga ../../modules/regulated/SKILL.md, e complete sua seção 0 (pré-condições de licença, regras de esquema, residência de dados e termos de fornecedor, pontos de contato de crime financeiro, conduta, a prova de auditoria métrica) antes que qualquer requisito seja escrito. Um campo de sobreposição em branco é uma decisão adiada para quem o encontrar em branco. Nomes de reguladores, números de seção e texto citado vêm apenas desse módulo ou de texto primário que o usuário fornece; nunca os invente.
Fluxo de trabalho
- Classifique o contexto. Regulado: siga a rota regulada acima, depois retorne aqui para seções que o módulo não cobre. Não regulado: comece de ../../templates/definition/prd.md.
- Leia o rascunho do PRD, ou entreviste o PM se começar em branco.
- Reescreva cada declaração "deve" na forma da seção 1. Liste aquelas que não podem ser transformadas em avaliações; essas ainda não são requisitos, sinalize-as.
- Construa as três tabelas de casos extremos. Insista por pelo menos 5 linhas cada; tabelas vazias significam que a descoberta não está concluída.
- Escreva a cláusula de não determinismo e a tabela de guardrails.
- Produza uma lista de LACUNAS (GAPS) de uma página: cada lugar onde o documento original assumiu um implementador determinístico, classificado por raio de explosão.
Formato de saída
Retorne o PRD reestruturado com as cinco seções, depois a tabela GAPS:
| # | Lacuna | Onde no original | Raio de explosão se enviado como está | Menor correção |
|---|
Portão de saída
A saída deste skill alimenta o Portão 2 em ../../os/STAGE-GATES.md. Não declare o PRD como concluído enquanto qualquer requisito não tiver uma condição de aprovação numérica, qualquer guardrail não tiver um proprietário e um teste, ou qualquer linha GAPS não tiver um proprietário e uma data.