메뉴
Quebra um plano, spec ou a conversa atual em um conjunto de tickets tracer-bullet, cada um declarando suas blocking edges, publicados no tracker configurado — edges como texto num arquivo local, ou links de blocking nativos num tracker de verdade.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | to-tickets |
| description | Quebra um plano, spec ou a conversa atual em um conjunto de tickets tracer-bullet, cada um declarando suas blocking edges, publicados no tracker configurado — edges como texto num arquivo local, ou links de blocking nativos num tracker de verdade. |
| disable-model-invocation | true |
Quebre um plano, spec ou conversa em um conjunto de tickets — vertical slices no estilo tracer bullet, cada um declarando os tickets que o bloqueiam.
O issue tracker e o vocabulário de triage labels devem ter sido fornecidos a você — rode /setup-leandrocfe-skills se não.
Trabalhe com o que já está no contexto da conversa. Se o usuário passar uma referência como argumento (o caminho de uma spec, um número ou URL de issue), busque-a e leia o corpo completo e os comentários.
Se ainda não explorou a codebase, explore para entender o estado atual do código. Títulos e descrições de ticket 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 de prefactor no código para facilitar a implementação. "Torne a mudança fácil, depois faça a mudança fácil."
Quebre o trabalho em tickets tracer bullet.
Dê a cada ticket suas blocking edges — os outros tickets que precisam estar concluídos antes que ele possa começar. Um ticket sem blockers pode começar imediatamente.
Wide refactors são a exceção ao vertical slicing. Um wide refactor é uma única mudança mecânica — renomear uma coluna, retipar um símbolo compartilhado — cujo blast radius se espalha pela codebase inteira: uma edição só quebra milhares de call sites de uma vez e nenhuma vertical slice consegue ficar verde. Não force isso num tracer bullet; sequencie como expand–contract. Primeiro expand: adicione a forma nova ao lado da antiga, para que nada quebre. Depois migre os call sites em lotes dimensionados pelo blast radius (por pacote, por diretório), cada lote sendo seu próprio ticket bloqueado pelo expand, mantendo o CI verde lote a lote porque a forma antiga ainda existe. Por fim contract: apague a forma antiga quando não restar nenhum caller, num ticket bloqueado por todos os lotes de migração. Quando nem os lotes conseguem ficar verdes sozinhos, mantenha a sequência mas deixe que compartilhem uma integration branch, e que todos bloqueiem um ticket final de integrar-e-verificar — o verde só é prometido ali.
Apresente a quebra proposta como uma lista numerada. Para cada ticket, mostre:
Pergunte ao usuário:
Itere até o usuário aprovar a quebra.
Publique os tickets aprovados. Como depende do tracker que o /setup-leandrocfe-skills configurou — os tickets são os mesmos nos dois casos, só muda a forma das blocking edges:
tickets.md na raiz do repo, todos os tickets em ordem de dependência (blockers primeiro), cada um com seu "Blocked by" listando os títulos dos quais depende. Use o template de arquivo abaixo.ready-for-agent salvo instrução em contrário — os tickets são pegáveis por agent por construção.NÃO feche nem modifique nenhuma issue pai.
Um resumo de uma linha do que estes tickets constroem. Referencie a spec de origem, se houver.
Trabalhe a frontier: qualquer ticket cujos blockers estejam todos concluídos. Numa cadeia puramente linear, isso significa de cima para baixo.
What to build: 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.
Blocked by: os títulos dos tickets que travam este, ou "Nenhum — pode começar imediatamente".
...
Uma referência à issue pai no tracker (se a origem foi uma issue existente; caso contrário, omita esta seção).
O comportamento ponta a ponta que este ticket faz funcionar, da perspectiva do usuário — não implementação camada por camada.
Em qualquer das formas, evite caminhos de arquivo específicos ou trechos de código — eles ficam obsoletos rápido. Exceção: se um prototype produziu um trecho que codifica uma decisão com mais precisão do que a prosa consegue (state machine, reducer, schema, formato de tipo), inclua-o e anote brevemente que veio de um prototype. Corte para as partes ricas em decisão — não é um demo funcional, só o que importa.
Trabalhe a frontier um ticket por vez com /implement, limpando o contexto entre tickets.
Sincroniza este repositório com um novo release do upstream (mattpocock/skills), adaptando as mudanças para pt-BR em vez de copiá-las. Use quando sair um release novo no upstream ou quando uma issue de "Sync upstream" for aberta pelo workflow check-upstream.
Pergunte qual skill ou fluxo encaixa na sua situação. Um router sobre as skills deste repo.
Revisa as mudanças desde um ponto fixo (commit, branch, tag ou merge-base) em dois eixos — Standards (o código segue os padrões de codificação documentados deste repo?) e Spec (o código faz o que a issue/spec de origem pediu?). Roda as duas revisões em sub-agents paralelos e reporta lado a lado. Use quando o usuário quiser revisar um branch, um PR, mudanças em andamento, ou pedir para "revisar desde X".
Implementa um pedaço de trabalho baseado em uma spec ou conjunto de tickets.
Constrói um prototype descartável para responder a uma pergunta de design. Use quando o usuário quiser checar se um modelo de estado ou uma lógica faz sentido, ou explorar como uma UI deveria ser.
Investiga uma pergunta contra fontes primárias de alta confiança e registra os achados como um arquivo Markdown no repo. Use quando o usuário quiser um tema pesquisado, fatos de docs ou de API reunidos, ou o trabalho braçal de leitura delegado a um background agent.