g-ki/agent-skills

Divisão de Tarefas

Transforme um design em um backlog de tickets de 1 ponto de história que qualquer engenheiro do time possa assumir, finalizar e mesclar por conta própria.

Entrada

$ARGUMENTS

• Se um caminho for fornecido, leia esse documento.
• Caso contrário, use o RFC mais recente ou *.notes.md de uma sessão de pensamento produtivo nesta conversa ou no disco. Geralmente são arquivos locais não rastreados (procure em pastas ignoradas pelo git, como .rfcs/, depois docs/rfcs/, docs/adr/, rfcs/). Se não encontrar nenhum, pergunte qual documento ou design deve ser dividido.
• Se a fonte tiver lacunas que impeçam o fatiamento (nenhum design escolhido, nenhuma abordagem de implantação), liste-as e pergunte antes de inventar respostas. Pequenas lacunas podem se tornar tickets de spike.

O que "1 ponto de história" significa aqui

Um ticket é 1 ponto quando todas as condições abaixo forem verdadeiras. Se uma falhar, divida-o:

1. Uma pessoa, cerca de um dia ou menos, incluindo testes e correções de revisão.
2. Um PR revisável com um único propósito. Um revisor consegue entendê-lo sem ler outros PRs abertos.
3. Mesclável por conta própria. A main permanece verde e publicável após a mesclagem, o que geralmente significa que o novo comportamento está atrás de uma flag ou ainda não está conectado.
4. Testável. Possui de 1 a 5 critérios de aceitação que alguém além do autor pode verificar.
5. Sem incógnitas ocultas. Se o implementador precisar pesquisar antes de saber o que fazer, é um spike, não uma história.

Se o time tiver sua própria definição de ponto, siga-a e anote isso no topo da saída.

Como fatiar

Leia o código antes de fatiar: confirme que os arquivos, módulos, esquemas e testes que cada ticket toca realmente existem e nomeie-os no ticket. Tickets que citam caminhos reais são assumidos; tickets vagos ficam no backlog.

Comece com um esqueleto funcional (walking skeleton): a fatia mais enxuta de ponta a ponta que prova que o design funciona em produção (geralmente atrás de uma flag), depois engrosse-o. Isso traz o risco para o início, em vez de descobrir problemas de integração no último ticket.

Quando um ticket for grande demais, essas divisões geralmente funcionam:

• Prepare, depois mude. Extraia uma refatoração pura primeiro ("facilite a mudança, depois faça a mudança fácil"), com testes que prendam o comportamento atual antes da refatoração.
• Expandir / migrar / contrair para mudanças de esquema e API: adicione a nova coluna ou endpoint, preencha ou faça escrita dupla, alterne as leituras, depois remova o caminho antigo. Cada fase é seu próprio ticket.
• Por camada atrás de uma flag: modelo de dados → lógica de serviço → API → UI, cada uma mesclável porque a flag está desligada.
• Caminho de leitura antes do caminho de escrita, e caminho feliz antes de casos de borda e tratamento de erros.
• Por variante: um ticket por provedor, tipo de arquivo ou cliente, depois que o primeiro estabelece o padrão.
• Spikes para incógnitas: com limite de tempo (≤ 1 dia), e a saída é uma decisão mais tickets de acompanhamento, não código de produção. Dê a cada spike uma Pergunta: que tenha uma resposta e um limite de tempo. Tickets que dependem da decisão são fatiados apenas até onde for seguro, com uma nota de que serão refinados assim que o spike for decidido. Coloque os spikes cedo: eles bloqueiam tudo que está atrás deles.

Não se esqueça do trabalho que não é código de funcionalidade: configuração e remoção de flags de funcionalidade, métricas/alertas/dashboards, atualizações de runbook ou documentação, preenchimento de dados, etapas de implantação gradual e limpeza do caminho antigo. Geralmente é aí que projetos "quase prontos" emperram.

Não divida por dividir: um ticket que só faz sentido se for mesclado junto com outro deve ser um único ticket, ou o par deve ser recortado por uma emenda diferente.

Saída

1. Escreva o backlog usando templates/tasks.md em <rfc-name>.tasks.md ao lado do RFC de origem. Assim como o RFC, é um arquivo de trabalho local, não rastreado por padrão; se sua pasta ainda não estiver no gitignore, adicione-a a .git/info/exclude. Numere os tickets T-01, T-02, … para que as dependências possam referenciá-los, defina todos os status como open e preencha o slug do projeto usado para nomes de branch. Mantenha os nomes dos campos exatamente como no template, pois /implement-task e /deliver-project os leem.
2. Agrupe os tickets em marcos que correspondam às fases do RFC, cada um terminando em algo demonstrável ou publicável.
3. Inclua o quadro de dependências: quais tickets podem rodar em paralelo e o caminho crítico. Um pequeno gráfico Mermaid funciona bem quando há mais de ~8 tickets.
4. No chat, dê um breve resumo: contagem de tickets por marco, quantos podem começar imediatamente, o caminho crítico, spikes e qualquer ticket sobre o qual você não tem certeza se é realmente 1 ponto. Peça ao usuário para sinalizar tickets que pareçam grandes demais, pequenos demais ou mal ordenados, e revise.
5. Publique no tracker do time. Suponha que o time use um (Linear, Jira, GitHub Issues, …). Quando o usuário estiver satisfeito com a divisão, ofereça-se para publicar através da ferramenta de tracker conectada; se nenhuma estiver conectada, diga qual conector ajudaria e ofereça um CSV com as colunas ID, Title, Description, Acceptance Criteria, Story Points, Milestone, Depends On, Labels como alternativa. Publique somente após o usuário confirmar, pois é visível para todo o time. Para cada ticket, crie uma issue com o título, uma descrição que se sustente sozinha (contexto, escopo, arquivos, fora de escopo, critérios de aceitação), estime 1, o marco e relações de bloqueio para suas dependências onde o tracker suportar. Depois, escreva a chave e o link de cada issue no campo Tracker: do arquivo local.
6. Aponte para o próximo passo: /implement-task <ticket-id> para um único ticket, /spike-task <ticket-id> para um spike, ou /deliver-project <tasks-file> para executar todo o backlog com uma equipe de agentes.

Se o RFC de origem tiver uma seção de plano de execução, atualize-a para linkar o arquivo de tarefas em vez de duplicar a lista.

Refinamento após um spike

Quando receber o registro de decisão de um spike decidido (status decided), atualize o backlog em vez de começar do zero:

1. Aplique as alterações aprovadas no backlog pelo registro: adicione tickets (continue a numeração T-NN, nunca reutilize IDs), altere escopo, critérios ou dependências dos tickets afetados e marque os tickets removidos como canceled com o motivo, em vez de deletá-los.
2. Re-verifique cada ticket alterado ou novo contra o teste de 1 ponto e atualize o resumo, o gráfico de dependências e o caminho crítico.
3. Atualize as seções do RFC que o registro lista.
4. Sincronize o tracker: crie as novas issues, atualize as alteradas e cancele as removidas, escrevendo as novas chaves no arquivo de tarefas. Se o usuário aprovou a decisão e suas alterações no backlog juntas, essa aprovação cobre esta sincronização; caso contrário, confirme primeiro.
5. Defina o spike como done e resuma o que mudou em algumas linhas.