mattpocock/to-tickets

Para Tickets

Transforme um plano, especificação ou conversa em um conjunto de tickets: fatias verticais tracer-bullet, cada uma declarando os tickets que a bloqueiam.

O tracker de issues e o vocabulário de rótulos de triagem devem ter sido fornecidos a você. Caso contrário, diga ao usuário para executar /setup-matt-pocock-skills.

Processo

1. Coletar contexto

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

2. Explorar o codebase (opcional)

Se você ainda não explorou o codebase, faça isso para entender o estado atual do código. Os títulos e descrições dos tickets devem usar o vocabulário do glossário de domínio do projeto e respeitar os ADRs na área que você está tocando.

Procure oportunidades para pré-fatorar o código para tornar a implementação mais fácil. "Torne a mudança fácil, depois faça a mudança fácil."

3. Rascunhar fatias verticais

Divida o trabalho em tickets tracer bullet.

• Cada fatia corta um caminho estreito, mas COMPLETO, através de todas as camadas (schema, API, UI, testes): vertical, NÃO uma fatia horizontal de uma única camada
• Uma fatia concluída é demonstrável ou verificável por si só
• Cada fatia tem um tamanho que cabe em uma única janela de contexto nova
• Qualquer pré-fatoração deve ser feita primeiro

Dê a cada ticket suas arestas de bloqueio: os outros tickets que devem ser concluídos antes que ele possa começar. Um ticket sem bloqueadores pode começar imediatamente.

Refatorações amplas são a exceção às fatias verticais. Uma refatoração ampla é uma única mudança mecânica (renomear uma coluna, redigitar um símbolo compartilhado) cujo raio de explosão se espalha por todo o codebase, de modo que uma única edição quebra milhares de pontos de chamada de uma vez e nenhuma fatia vertical pode ficar verde. Não force isso em um tracer bullet; sequencie como expandir–contrair. Primeiro expanda: adicione a nova forma ao lado da antiga para que nada quebre. Em seguida, migre os pontos de chamada em lotes dimensionados pelo raio de explosão (por pacote, por diretório), cada lote sendo seu próprio ticket bloqueado pela expansão, mantendo o CI verde lote a lote porque a forma antiga ainda existe. Finalmente, contraia: exclua a forma antiga quando não houver mais chamadores, em um ticket bloqueado por cada lote de migração. Quando nem mesmo os lotes conseguem ficar verdes sozinhos, mantenha a sequência, mas permita que eles compartilhem uma branch de integração que todos bloqueiam em um ticket final de integrar-e-verificar; o verde é prometido apenas ali.

4. Questionar o usuário

Apresente a decomposição proposta como uma lista numerada. Para cada ticket, mostre:

• Título: nome descritivo curto
• Bloqueado por: quais outros tickets (se houver) devem ser concluídos primeiro
• O que entrega: o comportamento ponta a ponta que este ticket faz funcionar

Pergunte ao usuário:

• A granularidade parece correta? (muito grossa / muito fina)
• As arestas de bloqueio estão corretas: cada ticket depende apenas de tickets que realmente o bloqueiam?
• Algum ticket deve ser mesclado ou dividido ainda mais?

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

5. Publicar os tickets no tracker configurado

Publique os tickets aprovados. Como depende do tracker que /setup-matt-pocock-skills configurou; os tickets são os mesmos de qualquer forma, apenas a forma das arestas de bloqueio muda:

• Arquivos locais → escreva um arquivo por ticket em .scratch/<feature-slug>/issues/<NN>-<slug>.md, numerados a partir de 01 na ordem de dependência (bloqueadores primeiro). Cada arquivo "Bloqueado por" lista os números/títulos dos quais depende. Use o modelo de arquivo por ticket abaixo: um ticket por arquivo, nunca um único arquivo combinado.
• Um tracker de issues real (GitHub, Linear, …) → publique uma issue por ticket na ordem de dependência (bloqueadores primeiro) para que as arestas de bloqueio de cada ticket possam referenciar identificadores reais. Use o relacionamento nativo de bloqueio / sub-issue da plataforma, se houver; caso contrário, defina o "Bloqueado por" de cada ticket para as issues bloqueadoras. Aplique o rótulo de triagem ready-for-agent a menos que instruído de outra forma; os tickets são, por construção, acessíveis por agentes.

Trabalhe na fronteira: qualquer ticket cujos bloqueadores estão todos concluídos. Para uma cadeia puramente linear, isso significa de cima para baixo.

NÃO feche ou modifique nenhuma issue pai.

: <Título do ticket>

O que construir: o comportamento ponta a ponta que este ticket faz funcionar, da perspectiva do usuário, não uma lista de implementação camada por camada.

Bloqueado por: os números/títulos dos tickets que bloqueiam este, ou "Nenhum (pode começar imediatamente)".

Status: ready-for-agent

• Critério de aceitação 1
• Critério de aceitação 2

Pai

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

O que construir

O comportamento ponta a ponta que este ticket faz funcionar, da perspectiva do usuário, não camada por camada de implementação.

Critérios de aceitação

• Critério 1
• Critério 2

Bloqueado por

• Uma referência a cada ticket bloqueador, ou "Nenhum (pode começar imediatamente)".

Em qualquer forma, evite caminhos de arquivo específicos ou trechos de código: eles ficam obsoletos rapidamente. Exceção: se um protótipo produziu um trecho que codifica uma decisão de forma mais precisa do que a prosa pode (máquina de estado, redutor, schema, formato de tipo), coloque-o inline e observe brevemente que veio de um protótipo. Apare as partes ricas em decisão, não uma demonstração funcional, apenas as partes importantes.