Matt Pocock lançou /wayfinder esta semana, a habilidade mais nova em seu repositório "AI Skills for Real Engineers" — agora com 220.000 estrelas no GitHub. A habilidade aborda uma falha específica: agentes executando durante a noite em tarefas de longo prazo que ninguém compreendeu completamente no começo. A ideia central: mover o planejamento da context window para o issue tracker.

O problema não é alucinação no sentido usual de LLM. É deterioração de limite de sessão. Quando Pocock executava agentes em projetos de múltiplos dias, a etapa de planejamento se tornava o gargalo. Ele precisava rastrear manualmente a profundidade de tokens, decidir o que avançava para a próxima sessão e manter o estado coerente do projeto através de resets de contexto. /wayfinder externaliza esse estado em um mapa — uma única issue no tracker do repositório rotulada wayfinder:map. O mapa contém todas as decisões já tomadas como issues filhas (tickets). O mapa é um índice, não um armazenamento: cada decisão existe em exatamente um ticket e o mapa cria um link para ele.

Cada ticket é dimensionado para uma sessão de agente de 100K tokens. A habilidade define quatro tipos de ticket: grilling (entrevista estruturada para resolver uma decisão), prototype (artefato concreto barato), research (investigação de contexto como um subagente paralelo) e task (qualquer coisa que o agente não consiga fazer). Uma sessão reclama um ticket atribuindo-o antes do trabalho começar; sessões concorrentes pulam tickets reclamados. Blocking edges usam links de dependência nativos do tracker. A frontier — tickets abertos, desbloqueados, não reclamados — é visível na interface do tracker sem abrir o mapa. Backends suportados: GitHub Issues, GitLab e markdown local.

A estrutura "fog of war" faz trabalho operacional, não decoração metafórica. Pocock descreve o problema de planejamento como exploração de mapa estilo Warcraft III: cada decisão resolvida revela novas decisões. Ele enfatiza o vocabulário como âncora operacional: "leading words" (map, ticket, frontier) fornecem aos agentes pontos de referência consistentes entre sessões. Quando o mesmo conceito recebe nomes diferentes em diferentes partes do prompt, ele diz, "você obtém comportamento estranho." A renomeação de /decision-mapping para /wayfinder refletiu isso: o nome antigo era "jargonesco e impreciso — apenas um tipo de ticket é realmente uma decisão."

O pipeline completo é /wayfinder → /to-spec → /to-tickets → /implement. Wayfinder fecha quando a rota está clara, significando que não há tickets de decisão abertos. /to-spec então colapsa decisões vinculadas em um artefato de spec; /to-tickets o fatia em tickets de implementação tracer-bullet com blocking edges. Pular /to-spec e ir direto para /implement é possível em esforços pequenos, mas "descarta o detalhe vinculado" em maiores. Research tickets são a exceção à regra de um ticket por sessão: a sessão de mapeamento aciona um subagente /research para cada um em paralelo.

O trabalho paralelo de tickets é tecnicamente suportado, mas o teto prático é baixo. Usuários executando dois grilling tickets simultaneamente recebem uma pergunta em uma sessão que acabaram de responder em outra, porque sessões não compartilham contexto. Um-de-cada-vez é o padrão recomendado até que agentes consigam ler o estado de sessões irmãs. Uma lacuna relatada: um agente selecionou entre três variações de interface que havia construído e fechou o ticket sem revisão humana.

A mudança subjacente é arquitetônica: decision tickets carregam decisões para fora de sessões do mesmo modo que context files carregam conhecimento. Wayfinder abandona a sessão como unidade de trabalho e move a fonte de verdade para o tracker. A aposta é que o issue tracker é um estado compartilhado mais confiável que a context window.