Para Issues

Quando Usar

Use quando este fluxo de trabalho corresponder à solicitação do usuário: Divida um plano, especificação ou PRD em issues que podem ser pegas independentemente no rastreador de issues do projeto usando fatias verticais de "tracer bullet".

Fonte: mattpocock/skills (MIT).

Divida um plano em issues que podem ser pegas independentemente usando fatias verticais (tracer bullets).

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. Reunir contexto

Trabalhe com o que já está no contexto da conversa. Se o usuário passar uma referência de issue (número da issue, URL ou caminho) como argumento, busque-a no rastreador de issues e leia seu corpo completo e comentários.

2. Explorar a base de código (opcional)

Se você ainda não explorou a base de código, faça-o para entender o estado atual do código. Títulos e descrições de issues devem usar o vocabulário do glossário de domínio do projeto e respeitar os ADRs na área que você está abordando.

Procure oportunidades para refatorar o código para facilitar a implementação. "Torne a mudança fácil, depois faça a mudança fácil."

3. Rascunhar fatias verticais

Divida o plano em issues de tracer bullet. Cada issue é uma fina fatia vertical que atravessa TODAS as camadas de integração de ponta a ponta, NÃO uma fatia horizontal de uma camada.

• Cada fatia entrega um caminho estreito, mas COMPLETO, através de todas as camadas (schema, API, UI, testes)
• Uma fatia concluída é demonstrável ou verificável por si só
• Qualquer refatoração deve ser feita primeiro

4. Perguntar ao usuário

Apresente a divisão proposta como uma lista numerada. Para cada fatia, mostre:

• Título: nome descritivo curto
• Bloqueado por: quais outras fatias (se houver) devem ser concluídas primeiro
• Histórias de usuário cobertas: quais histórias de usuário esta aborda (se o material de origem as tiver)

Pergunte ao usuário:

• A granularidade parece correta? (muito grossa / muito fina)
• Os relacionamentos de dependência estão corretos?
• Alguma fatia deve ser mesclada ou dividida ainda mais?

Itere até que o usuário aprove a divisão.

5. Publicar as issues no rastreador de issues

Para cada fatia aprovada, publique uma nova issue no rastreador de issues. Use o modelo de corpo da issue abaixo. Essas issues são consideradas prontas para agentes AFK, portanto, publique-as com o rótulo de triagem correto, a menos que instruído de outra forma.

Publique as issues na ordem de dependência (bloqueadores primeiro) para que você possa referenciar identificadores reais de issues no campo "Bloqueado por".

Uma referência à issue pai no rastreador de issues (se a origem foi uma issue existente, caso contrário, omita esta seção).

O que construir

Uma descrição concisa desta fatia vertical. Descreva o comportamento de ponta a ponta, não a implementação camada por camada.

Evite caminhos de arquivo específicos ou trechos de código — eles ficam desatualizados 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, redutor, schema, forma de tipo), incorpore-o aqui e observe brevemente que ele veio de um protótipo. Corte as partes ricas em decisões — não uma demonstração funcional, apenas os bits importantes.

Critérios de aceitação

• Critério 1
• Critério 2
• Critério 3

Bloqueado por

• Uma referência ao ticket bloqueador (se houver)

Ou "Nenhum - pode começar imediatamente" se não houver bloqueadores.

NÃO feche ou modifique nenhuma issue pai.

Exemplo

Solicitação do usuário:

Use @to-issues para esta tarefa: Divida um plano, especificação ou PRD em issues que podem ser pegas independentemente no rastreador de issues do projeto usando fatias verticais de tracer bullet.

Limitações

• Requer a ferramenta upstream, conta, chave de API ou configuração local quando o fluxo de trabalho nomeia uma.
• 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 gerados contra as fontes reais do usuário antes de tratá-los como finais.