メニュー
Planeja um pedaço enorme de trabalho — maior do que uma sessão de agent consegue segurar — como um mapa compartilhado de tickets de investigação no seu issue tracker, e resolve um ticket por vez até que o caminho até o destino esteja claro.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
| name | wayfinder |
| description | Planeja um pedaço enorme de trabalho — maior do que uma sessão de agent consegue segurar — como um mapa compartilhado de tickets de investigação no seu issue tracker, e resolve um ticket por vez até que o caminho até o destino esteja claro. |
| disable-model-invocation | true |
Chegou uma ideia solta — grande demais para uma sessão de agent, e envolta em névoa: o caminho daqui até o destino ainda não é visível. Wayfinding é sobre achar esse caminho, não sobre partir para cima do destino. Esta skill traça o caminho como um mapa compartilhado no issue tracker do repo, e então trabalha os tickets dele um por vez até a rota ficar clara.
O destino varia a cada empreitada, e nomeá-lo é o primeiro ato de traçar o mapa — ele molda cada ticket. Pode ser uma spec para entregar e iterar, uma decisão a travar antes de o planejamento começar, ou uma mudança feita no lugar, como uma migração de estrutura de dados. O mapa é agnóstico de domínio — trabalho de engenharia, conteúdo de curso, o que couber no formato.
Wayfinder é planejamento por padrão: cada ticket resolve uma decisão, e o mapa termina quando o caminho está claro — nada restando a decidir antes que alguém vá e faça a coisa. A vontade de simplesmente executar o trabalho é, em geral, o sinal de que você chegou à borda do mapa e é hora de fazer o handoff. Uma empreitada pode sobrescrever isso nas suas Notes — trazendo a execução para dentro do próprio mapa — mas, na ausência disso, produza decisões, não entregáveis.
Todo mapa e todo ticket é uma issue, então tem um nome — seu título. Em tudo que o humano lê — narração, o Decisions-so-far do mapa — refira-se a ele por esse nome, nunca por um id, número ou slug pelado. Uma parede de #42, #43, #44 é ilegível; nomes se leem de relance. O id e a URL não somem — um nome embrulha seu link — mas eles viajam dentro do nome, nunca no lugar dele.
O mapa é uma única issue no issue tracker deste repo, com a label wayfinder:map — o artefato canônico. Seus tickets são issues-filhas do mapa.
O mapa é um índice, não um armazém. Ele lista as decisões tomadas e aponta para os tickets que guardam o detalhe delas; uma decisão vive em exatamente um lugar — seu ticket — então o mapa nunca a repete, apenas resume e linka.
Onde o mapa, seus tickets-filhos, o blocking e as queries de frontier moram fisicamente é específico do tracker. O issue tracker deve ter sido fornecido a você — rode /setup-leandrocfe-skills se não. Consulte a seção "Wayfinding operations" do doc do tracker para saber como este repo os expressa. Se nenhum tracker tiver sido fornecido, use o tracker local-markdown como padrão.
O mapa inteiro em baixa resolução, carregado uma vez por sessão. Tickets abertos não são listados — eles são issues-filhas abertas, encontradas por query.
## Destination
<como é chegar ao fim deste mapa — a spec, decisão ou mudança que esta empreitada está buscando. Uma ou duas linhas; toda sessão se orienta por isso antes de escolher um ticket.>
## Notes
<domínio; skills que toda sessão deve consultar; preferências permanentes desta empreitada>
## Decisions so far
<!-- o índice — uma linha por ticket fechado: o suficiente para julgar relevância, depois dê zoom no link para o detalhe que o ticket guarda -->
- [<título do ticket fechado>](link) — <resumo de uma linha da resposta>
## Not yet specified
<!-- veja "Fog of war": névoa dentro do escopo que você ainda não consegue transformar em ticket; gradua conforme a frontier avança -->
## Out of scope
<!-- veja "Out of scope": trabalho decidido como além do destino; fechado, nunca gradua -->
Cada ticket é uma issue-filha do mapa; o id da issue no tracker é sua identidade. Seu corpo é a pergunta, dimensionada para uma sessão de agent de 100K tokens:
## Question
<a decisão ou investigação que este ticket resolve>
Cada ticket carrega uma label wayfinder:<tipo> — uma de research, prototype, grilling, task (veja Tipos de ticket).
Uma sessão reivindica (claim) um ticket atribuindo-o ao dev que está conduzindo o mapa, primeiro, antes de qualquer trabalho, para que sessões concorrentes o pulem. Esse assignee é a reivindicação: um ticket aberto e sem assignee está livre.
O blocking usa a relação de dependência nativa do tracker — essencial porque ela renderiza a frontier visualmente na própria UI do tracker, e assim o humano vê o que é pegável sem abrir o mapa. Só um tracker que não tenha blocking nativo cai no fallback de convenção no corpo. Um ticket está desbloqueado quando todo ticket que o bloqueia está fechado; a frontier são os filhos abertos, desbloqueados e não reivindicados — a borda do conhecido.
A resposta não faz parte do corpo — ela é registrada na resolução (veja Trabalhar o mapa). Assets criados ao resolver um ticket são linkados da issue, não colados dentro dela.
Todo ticket é ou HITL — human in the loop, trabalhado com um humano que fala por si — ou AFK, conduzido pelo agent sozinho. Um ticket HITL só se resolve através dessa troca ao vivo; o agent nunca faz as vezes do lado humano dela (um agent de grilling que responde às próprias perguntas quebrou isso).
O mapa é deliberadamente incompleto: não trace o que você ainda não consegue ver. Além dos tickets vivos está a fog of war — a visão turva de decisões e investigações que você percebe que estão vindo mas ainda não consegue fixar, porque dependem de perguntas ainda abertas. Resolver um ticket dissipa a névoa à frente dele, graduando o que agora é especificável em tickets novos — um por vez, até que o caminho até o destino esteja claro e não reste nenhum ticket.
A seção Not yet specified do mapa é onde essa visão turva é anotada: a pergunta suspeita, a área a revisitar depois. É a frontier ainda não descoberta rumo ao destino — tudo aqui está no escopo, só não está nítido o bastante para virar ticket. Escreva de forma tão solta ou tão completa quanto a visão permitir; isso também serve de placa para colaboradores lendo para onde a empreitada está indo.
Névoa ou ticket? O teste é se você consegue enunciar a pergunta com precisão agora — não se consegue respondê-la agora.
Not yet specified exclui o que já foi decidido (Decisions so far), o que já é um ticket vivo, e o que está fora do escopo (a próxima seção).
A névoa só se acumula rumo ao destino. O destino fixa o escopo, então trabalho além dele está out of scope — não é névoa, e não pertence a Not yet specified. Ele ganha sua própria seção Out of scope no mapa: trabalho que você conscientemente descartou desta empreitada. É o escopo, não a nitidez, que o coloca ali.
Trabalho out-of-scope nunca gradua — a frontier para no destino — então ele só volta se o destino for redesenhado, e aí como uma empreitada nova, não como retomada.
Declarar algo fora de escopo é um ato de escopo, não um passo na rota. Quando um ticket que já existe se revela além do destino — mal-escopado durante o traçado, ou exposto por uma resolução — feche-o (um ticket fechado está inequivocamente fora da frontier) e deixe uma linha na seção Out of scope: o resumo mais o porquê de estar fora, linkando o ticket fechado. Ele fica de fora de Decisions so far, que registra a rota efetivamente percorrida — uma fronteira de escopo não é um passo nela.
Dois modos. Em qualquer um deles, nunca resolva mais de um ticket por sessão.
O usuário invoca com uma ideia solta.
/grilling e /domain-modeling para fixar o que este mapa está buscando — a spec, decisão ou mudança. O destino fixa o escopo, então ele é resolvido primeiro.wayfinder:map): Destination e Notes preenchidos, Decisions-so-far vazio, a névoa esboçada em Not yet specified.O usuário invoca com um mapa (URL ou número). Um ticket é opcional — sem ele, quem escolhe a próxima decisão é você, não o usuário.
## Notes nomear. Na dúvida, use /grilling e /domain-modeling.O usuário pode rodar tickets desbloqueados em paralelo, então espere que outras sessões estejam editando o tracker concorrentemente.