Matt Pocock lanzó /wayfinder esta semana, la habilidad más nueva en su repositorio "AI Skills for Real Engineers" — ahora con 220.000 estrellas en GitHub. La habilidad aborda una falla específica: agentes ejecutando durante la noche en tareas de largo horizonte que nadie comprendía completamente al inicio. La idea central: mover la planificación de la context window al issue tracker.

El problema no es alucinación en el sentido usual de LLM. Es deterioro de límite de sesión. Cuando Pocock ejecutaba agentes en proyectos de múltiples días, la etapa de planificación se convertía en el cuello de botella. Tenía que rastrear manualmente la profundidad de tokens, decidir qué se llevaba a la siguiente sesión y mantener el estado coherente del proyecto a través de resets de contexto. /wayfinder externaliza ese estado en un mapa — una única issue en el tracker del repositorio etiquetada wayfinder:map. El mapa contiene todas las decisiones ya tomadas como issues secundarias (tickets). El mapa es un índice, no un almacén: cada decisión existe en exactamente un ticket y el mapa vincula a él.

Cada ticket se dimensiona para una sesión de agente de 100K tokens. La habilidad define cuatro tipos de ticket: grilling (entrevista estructurada para resolver una decisión), prototype (artefacto concreto económico), research (investigación de contexto como un subagente paralelo) y task (cualquier cosa que el agente no pueda hacer). Una sesión reclama un ticket asignándolo antes de que comience el trabajo; las sesiones concurrentes omiten tickets reclamados. Los blocking edges utilizan enlaces de dependencia nativos del tracker. La frontier — tickets abiertos, desbloqueados, no reclamados — es visible en la interfaz del tracker sin abrir el mapa. Backends soportados: GitHub Issues, GitLab y markdown local.

El encuadre "fog of war" realiza trabajo operacional, no decoración metafórica. Pocock describe el problema de planificación como exploración de mapa estilo Warcraft III: cada decisión resuelta revela nuevas decisiones. Enfatiza el vocabulario como ancla operacional: "palabras principales" (map, ticket, frontier) dan a los agentes puntos de referencia consistentes entre sesiones. Cuando el mismo concepto recibe nombres diferentes en diferentes partes del prompt, dice, "obtienes comportamiento extraño." El cambio de nombre de /decision-mapping a /wayfinder reflejó esto: el nombre anterior era "jerga e inexacto — solo un tipo de ticket es realmente una decisión."

El pipeline completo es /wayfinder → /to-spec → /to-tickets → /implement. Wayfinder se cierra cuando la ruta está clara, lo que significa que no quedan tickets de decisión abiertos. /to-spec luego colapsa decisiones vinculadas en un artefacto de especificación; /to-tickets lo divide en tickets de implementación tracer-bullet con blocking edges. Omitir /to-spec e ir directamente a /implement es posible en esfuerzos pequeños pero "descarta el detalle vinculado" en los más grandes. Los research tickets son la excepción a la regla de un ticket por sesión: la sesión de mapeamiento dispara un subagente /research para cada uno en paralelo.

El trabajo paralelo de tickets es técnicamente soportado pero el techo práctico es bajo. Los usuarios que ejecutan dos grilling tickets simultáneamente reciben en una sesión una pregunta que acaban de responder en la otra, porque las sesiones no comparten contexto. Uno-a-la-vez es el valor predeterminado recomendado hasta que los agentes puedan leer el estado de sesiones hermanas. Una brecha reportada: un agente seleccionó entre tres variaciones de interfaz que había construido y cerró el ticket sin revisión humana.

El cambio subyacente es arquitectónico: los decision tickets sacan decisiones de las sesiones de la misma manera que los context files sacan conocimiento. Wayfinder abandona la sesión como unidad de trabajo y mueve la fuente de verdad al tracker. La apuesta es que el issue tracker es un estado compartido más confiable que la context window.