Un documento de plan es el artefacto equivocado para trabajo de IA que abarca múltiples sesiones. Aprendí esto de la manera cara: el razonamiento que produjo un plan vive en la conversación, y la conversación muere cuando la sesión termina. La siguiente sesión lee tu hermoso plan en markdown y reconstruye con confianza una suposición que ya habías descartado hace dos días. La skill Wayfinder, del pack de engineering skills de Matt Pocock, es la primera herramienta que he visto que trata esto como el problema central en vez de una nota al pie.
Uso Claude Code diariamente en una monorepo de Laravel, builds de clientes y pipelines de contenido, y casi todo lo que vale la pena hacer es más grande que una sesión. Aquí está cómo Wayfinder realmente funciona, lo que mi propio workflow de múltiples sesiones me enseñó antes de encontrarlo, y los casos específicos donde recurrir a él es un error.
Lo que un proyecto multi-sesión me enseñó antes de que Wayfinder existiera
El mes pasado reescribí 84 posts del blog en este sitio en siete lotes y más de una docena de sesiones de Claude Code. Lo que evitó que colapsara no fue un documento de plan. Fue un pequeño archivo tonto llamado REWRITE-STATUS.json — un manifiesto que listaba cada ID de post con una bandera DONE o PENDING, actualizado por un script mark_done.php después de que cada lote fue aplicado y verificado.
Cualquier sesión nueva podía leer ese manifiesto en dos segundos y saber exactamente dónde estaba el proyecto. Sin resumir la conversación anterior, sin re-derivar el estado del historial de git. El manifiesto era la memoria del proyecto; las sesiones eran desechables.
Pero un manifiesto solo rastrea trabajo. No puede decirle a una sesión nueva por qué el lote tres cambió los formatos de enlace, o por qué dejamos de confiar en una categoría de fuentes. Esas fueron decisiones, debatidas en conversaciones que ya no existen. Esa brecha — decisiones duraderas, no solo estado duradero — es precisamente lo que Wayfinder llena.
Lo que la skill Wayfinder realmente hace
Wayfinder traza un gran esfuerzo como un mapa de tickets de decisión en el issue tracker de tu repo, luego los resuelve uno a la vez a lo largo de tantas sesiones como sea necesario. Dos ideas lo hacen funcionar:
El ticket es una pregunta, no una tarea. Un ticket de Wayfinder nunca es "construye el motor de prorrateo." Es "¿cómo manejamos los cambios de plan a mitad de ciclo cuando el cliente tiene crédito sin usar?" Resolver un ticket produce una decisión, registrada permanentemente en el ticket. No es una porción del build.
El mapa es un índice, no un almacén. El mapa es un solo issue etiquetado wayfinder:map. Los issues hijos son los tickets. Cada decisión vive en exactamente un lugar — su propio ticket — y el mapa solo la resume y enlaza. Sin copias duplicadas divergiendo.
El issue del mapa lleva cinco secciones: Destination (una o dos líneas nombrando el punto final), Notes (contexto del dominio que cada sesión necesita), Decisions so far (tickets cerrados, resumidos y enlazados), Not yet specified (la niebla), y Out of scope (trabajo explícitamente excluido).
La línea de Destination hace más trabajo del que parece. Hazla vaga y cada ticket descendiente hereda la vaguedad.
Fog of war: la prueba que se transfiere a todas partes
Wayfinder toma prestado el concepto de fog of war de los juegos de estrategia. Tus tickets son el área iluminada — preguntas que puedes formular con precisión hoy. Más allá hay niebla: "hay algo sobre jurisdicciones fiscales aquí, aún no puedo formularlo." No planeas una ruta a través de la niebla. Avanzas hasta la frontera, revelas más terreno, luego decides.
La prueba para niebla versus ticket es directa: ¿puedes formular la pregunta con precisión, ahora mismo? Sí significa ticket. No significa niebla.
Ahora aplico esa prueba fuera de Wayfinder por completo. La mitad de los tickets que solía escribir para proyectos de clientes eran niebla disfrazada de ticket — lo suficientemente vagos como para que quien los tomara pasara la primera hora re-derivando cuál era la pregunta siquiera.
Dos términos más importan. La frontier es el conjunto de tickets abiertos, no bloqueados, no reclamados — decisiones que realmente se pueden tomar ahora mismo. Reclamar significa asignarte un ticket antes de trabajar en él, para que dos sesiones paralelas no resuelvan la misma pregunta de dos maneras diferentes. Ejecuto agentes paralelos en git worktrees constantemente, y el fallo recurrente es exactamente ese: dos agentes tomando decisiones incompatibles en los mismos veinte minutos.
Los cuatro tipos de ticket, y el que sale mal
Cada ticket lleva una etiqueta de tipo que determina qué skill lo resuelve y si necesitas estar presente:
| Tipo | Modo | Qué resuelve |
|---|---|---|
grilling |
Humano en el bucle | Preguntas resueltas por conversación — el predeterminado |
prototype |
Humano en el bucle | Preguntas de comportamiento o estéticas que necesitan un artefacto real |
research |
Agente trabaja solo | Hechos externos que bloquean una decisión; se ejecuta en paralelo |
task |
Ambos | Prerrequisitos manuales que desbloquean una decisión |
Grilling es el caballo de batalla — un Q&A adversarial que presiona tu plan hasta que la rama se resuelve. Tengo grill-me y grill-with-docs del mismo pack instalados en esta máquina y los uso semanalmente; grill-with-docs también actualiza CONTEXT.md y ADRs conforme las decisiones cristalizan, que es exactamente lo que un ticket de decisión debería alimentar.
Research cambia la economía. Estos se disparan como subagentes, en paralelo, mientras estás en otro lugar. Cuatro tickets de research se resuelven en el tiempo que toma una sesión de grilling.
Prototype existe porque algunas preguntas no pueden responderse en prosa. "¿Wizard o formulario único?" se resuelve con un artefacto desechable — sin tests, sin abstracciones, eliminado una vez que ha respondido la pregunta.
Task es el tipo que más sale mal, y la propia documentación de la skill lo admite. Un ticket de task es trabajo manual que desbloquea una decisión — aprovisionar la base de datos de staging, obtener credenciales de API. Los agentes consistentemente lo reinterpretan como un paso de implementación y comienzan a construir código de producción dentro del límite de planificación. Vigila tus tickets task.
Cómo transcurre una ejecución, sesión por sesión
Sesión uno: cartografiar. Llegas con un destino difuso — "migrar facturación a basado en uso este trimestre." El agente te interroga hasta que el Destination sea una o dos líneas concretas, mapea la frontier breadth-first (cartografiar depth-first te arrastra por una rama hasta que una rama hermana la invalida), crea el issue del mapa y los tickets que puedes formular hoy, conecta bordes reales de bloqueo entre ellos, coloca el resto en niebla, y dispara los subagentes de research. Luego se detiene. Cartografiar es una sesión.
Sesiones dos a N: trabajar el mapa. Cada sesión carga el mapa en baja resolución — Destination, Notes, Decisions so far, frontier — no cada cuerpo de ticket. Reclamas un ticket de frontier. El agente lo resuelve con la skill correspondiente, publica la resolución como comentario, cierra el ticket, lo resume en Decisions so far, crea cualquier ticket que la resolución reveló, gradúa niebla que ahora es lo suficientemente clara para formular. Y se detiene.
Ese "y se detiene" sostiene todo el sistema. Una decisión por sesión significa que cada decisión obtiene una ventana de contexto fresca de capacidad de juicio. Las sesiones que continúan toman tres decisiones en una ventana que solo tenía buen juicio para una. Esta es la misma disciplina que mi manifiesto de reescritura impuso por accidente: incrementos pequeños y verificados, estado escrito, sesión descartada.
El mapa se resuelve. Eventualmente la frontier se vacía y la niebla desaparece. Lo que tienes es una red de decisiones enlazadas con los argumentos intactos — no un plan de build. El paso final lo convierte: en la versión actual del pack, /to-spec colapsa las decisiones en una especificación y /to-tickets la corta en trabajo de implementación. Mi propia instalación aún muestra los antiguos /to-prd y /to-issues en ~/.claude/skills/, lo que me dice claramente que mi pack es anterior a ese cambio de nombre — vale la pena verificar qué par tienes antes de asumir que Wayfinder está instalado.
La configuración es un solo paso: instala el pack desde el repo mattpocock/skills o el marketplace de plugins de Claude Code, luego ejecuta /setup-matt-pocock-skills una vez por repo. Registra qué issue tracker usa el repo (GitHub vía gh, GitLab vía glab, markdown local para repos sin remote, o una descripción en prosa de tu workflow de Jira/Linear), tus etiquetas de triage, y dónde viven los docs del dominio. Esa opción de prosa es por qué llamarlo agnóstico de tracker es justo: no envía una integración con Jira, envía un lugar para escribir cómo funciona tu tracker.
Una decisión de diseño que vale la pena destacar: las relaciones de bloqueo usan las funciones nativas de dependencia del tracker, nunca una convención en el cuerpo del issue. Si "Blocked by: #42" es texto en una descripción, solo el agente que lo escribió lo entiende. Si es un borde real de bloqueo, GitHub renderiza el grafo de dependencias y la frontier se convierte en algo que puedes ver.
Cómo difiere del desarrollo dirigido por spec
Los frameworks dirigidos por spec — Spec Kit, Kiro, OpenSpec, que usé como herramienta diaria durante un tiempo — tratan la spec como la fuente persistente de verdad. Wayfinder se sitúa aguas arriba de todos ellos: es lo que ejecutas cuando hay demasiada niebla para escribir una spec en absoluto. Y su output de spec es deliberadamente desechable — un hito, no un documento mantenido.
Esa es la inversión que vale la pena mantener: el desarrollo tradicional dirigido por spec dice que el documento es permanente y el razonamiento es desechable. Wayfinder dice que el razonamiento es permanente y el documento es desechable. Habiendo visto lo que pasa con los documentos de spec después de seis meses, creo que Wayfinder lo tiene al revés correcto.
Cuándo no recurriría a él
La planificación cabe en una sesión. La mayoría del trabajo califica. Usa /grill-with-docs y termina en cuarenta minutos; un mapa, cuatro tipos de ticket y convenciones de reclamo son pura sobrecarga para una feature acotada.
La ruta es clara y solo el trabajo es grande. Grande no es el detonante — nebuloso lo es. Mi reescritura de 84 posts fue grande pero nunca nebulosa; un manifiesto y disciplina de lotes la cubrieron. Una migración de doce semanas donde conoces cada paso necesita agentes de implementación paralelos, no cartografía.
No tienes un tracker que realmente uses. El respaldo de markdown local funciona, pero pierdes bordes nativos de bloqueo y la frontier visible, que es la mayor parte del valor mecánico.
Encuentras agotador el Q&A adversarial. El grilling es exhaustivo — cada pregunta llega como tres párrafos. Una instrucción en CLAUDE.md para hacer una pregunta corta a la vez ayuda, pero no lo soluciona completamente. Presupuesta eso antes de cartografiar un mapa de veinte tickets.
Para continuidad sesión a sesión en trabajo que no necesita un mapa completo de decisiones, la skill handoff es la herramienta más ligera, y nada de esto reemplaza la gestión básica de contexto en sesiones largas — una ventana más grande compra espacio, no continuidad.
El reencuadre que mantengo de todos modos: deja de escribir planes, empieza a cerrar preguntas. Un plan es una afirmación sobre un futuro que no puedes ver. Un ticket de decisión cerrado es un hecho con el argumento adjunto, y sobrevive cada reseteo de contexto. Abre el documento de plan de tu proyecto actual y cuenta qué líneas son decisiones con razonamiento detrás y cuáles son conjeturas con voz confiada. Las conjeturas son tu niebla — y ahora sabes cuánto del mapa nunca cartografiaste.
Wayfinder es una de docenas de skills que he evaluado contra trabajo real de proyectos. Si estás decidiendo cuáles merecen un lugar en tu propia configuración, mi agent skills marketplace es donde guardo las que se ganaron su lugar.
