to-prd

Quando Usar

Use quando este fluxo de trabalho corresponder à solicitação do usuário: Transformar a conversa atual em um PRD e publicá-lo no rastreador de issues do projeto — sem entrevista, apenas síntese do que já foi discutido.

Fonte: mattpocock/skills (MIT). Esta habilidade utiliza o contexto da conversa atual e o entendimento do codebase para produzir um PRD. NÃO entreviste o usuário — apenas sintetize o que você já sabe.

O vocabulário do rastreador de issues e dos rótulos de triagem deve ter sido fornecido a você — execute /setup-matt-pocock-skills se não.

Processo

1. Explore o repositório para entender o estado atual do codebase, se ainda não o fez. Use o vocabulário do glossário de domínio do projeto em todo o PRD e respeite quaisquer ADRs na área que você está abordando.

2. Esboce os "seams" (pontos de conexão/interrupção) onde você testará o recurso. "Seams" existentes devem ser preferidos a novos. Use o "seam" mais alto possível. Se novos "seams" forem necessários, proponha-os no ponto mais alto que puder. Quanto menos "seams" no codebase, melhor — o número ideal é um.

Verifique com o usuário se esses "seams" correspondem às suas expectativas.

3. Escreva o PRD usando o template abaixo e, em seguida, publique-o no rastreador de issues do projeto. Aplique o rótulo de triagem ready-for-agent — não há necessidade de triagem adicional.

<prd-template>

Declaração do Problema

O problema que o usuário está enfrentando, da perspectiva do usuário.

Solução

A solução para o problema, da perspectiva do usuário.

Histórias de Usuário

Uma lista LONGA e numerada de histórias de usuário. Cada história de usuário deve estar no formato:

1. Como um(a) <ator>, eu quero <funcionalidade>, para que <benefício>

<user-story-example> 1. Como um cliente de banco móvel, eu quero ver o saldo das minhas contas, para que eu possa tomar decisões mais informadas sobre meus gastos </user-story-example>

Esta lista de histórias de usuário deve ser extremamente extensa e cobrir todos os aspectos da funcionalidade.

Decisões de Implementação

Uma lista de decisões de implementação que foram tomadas. Isso pode incluir:

• Os módulos que serão construídos/modificados
• As interfaces desses módulos que serão modificadas
• Esclarecimentos técnicos do desenvolvedor
• Decisões arquiteturais
• Mudanças de esquema
• Contratos de API
• Interações específicas

NÃO inclua caminhos de arquivo específicos ou trechos de código. Eles podem ficar desatualizados muito rapidamente.

Exceção: se um protótipo produziu um trecho que codifica uma decisão com mais precisão do que a prosa pode (máquina de estados, reducer, esquema, forma de tipo), incorpore-o dentro da decisão relevante e observe brevemente que ele veio de um protótipo. Corte para as partes ricas em decisões — não uma demonstração funcional, apenas os pontos importantes.

Decisões de Teste

Uma lista de decisões de teste que foram tomadas. Inclua:

• Uma descrição do que torna um bom teste (apenas teste o comportamento externo, não os detalhes de implementação)
• Quais módulos serão testados
• Artefatos anteriores para os testes (ou seja, tipos semelhantes de testes no codebase)

Fora do Escopo

Uma descrição das coisas que estão fora do escopo para este PRD.

Notas Adicionais

Quaisquer notas adicionais sobre a funcionalidade.

</prd-template>

Exemplo

Solicitação do usuário:

Transforme a conversa atual em um PRD e publique-o no rastreador de issues do projeto — sem entrevista, apenas síntese do que já foi discutido.

Limitações

• Requer a ferramenta upstream, conta, chave de API ou configuração local quando o fluxo de trabalho a nomeia.
• Não autoriza ações destrutivas, de produção, pagas ou de mensagens externas sem aprovação explícita do usuário.
• Valide artefatos ou recomendações geradas contra as fontes reais do usuário antes de tratá-las como finais.