メニュー
Planifica un trozo de trabajo enorme — más de lo que cabe en una sesión de agente — como un mapa compartido de tickets de decisión en tu issue tracker, y resuélvelos de uno en uno hasta que el camino al destino esté despejado.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/KroxiDev/claude-dev-skills --skill wayfinderコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Modo de respuesta ultracomprimida — habla como un cavernícola inteligente. Niveles lite (por defecto), full y ultra.
Una entrevista sin descanso que hace todas las preguntas del frontier a la vez, ronda a ronda.
Traspasa la tarea actual a otra sesión del mismo workspace — un prompt copiable por defecto, o un documento markdown si lo pides.
SOC 職業分類に基づく
SKILL.md を表示中
| name | wayfinder |
| description | Planifica un trozo de trabajo enorme — más de lo que cabe en una sesión de agente — como un mapa compartido de tickets de decisión en tu issue tracker, y resuélvelos de uno en uno hasta que el camino al destino esté despejado. |
| disable-model-invocation | true |
Ha llegado una idea suelta — demasiado grande para una sesión de agente, y envuelta en niebla: el camino desde aquí hasta el destino aún no es visible. Wayfinding va de encontrar ese camino, no de embestir hacia el destino. Este skill traza el camino como un mapa compartido en el issue tracker del repo, y luego trabaja sus tickets de decisión — preguntas cuya resolución es una decisión, no slices de una construcción a ejecutar — de uno en uno hasta que la ruta esté clara.
El destino varía según el esfuerzo, y nombrarlo es el primer acto del trazado — da forma a cada ticket. Puede ser una spec que entregar e iterar, una decisión que fijar antes de que empiece la planificación, o un cambio hecho en el sitio, como una migración de estructura de datos. El mapa es agnóstico del dominio — trabajo de ingeniería, contenido de un curso, lo que encaje con la forma.
Wayfinder es planificación por defecto: cada ticket resuelve una decisión, y el mapa está terminado cuando el camino está despejado — no queda nada por decidir antes de que alguien vaya y haga la cosa. El tirón de simplemente hacer el trabajo suele ser la señal de que has llegado al borde del mapa y toca traspasar. Un esfuerzo puede sobreescribir esto en sus Notas — llevando la ejecución al propio mapa — pero en ausencia de eso, produce decisiones, no entregables.
Cada mapa y ticket es un issue, así que tiene un nombre — su título. En todo lo que lea el humano — la narración, las Decisiones-hasta-ahora del mapa — referirse a él por ese nombre, nunca por un id, número o slug a secas. Un muro de #42, #43, #44 es ilegible; los nombres se leen de un vistazo. El id y la URL no desaparecen — un nombre envuelve su enlace — pero viajan dentro del nombre, nunca lo sustituyen.
El mapa es un único issue en el issue tracker de este repo, etiquetado wayfinder:map — el artefacto canónico. Sus tickets son issues hijos del mapa.
El mapa es un índice, no un almacén. Lista las decisiones tomadas y apunta a los tickets que guardan su detalle; una decisión vive en exactamente un lugar — su ticket — así que el mapa nunca la reformula, solo la resume y enlaza.
Dónde viven físicamente el mapa, sus tickets hijos, los bloqueos y las consultas de frontier es específico de cada tracker. La configuración del issue tracker debería estar ya proporcionada — si no, preguntar al usuario. Consultar la sección "Wayfinding operations" del doc del tracker para saber cómo los expresa este repo. Si no hay tracker configurado, usar por defecto el tracker de Markdown local.
El mapa completo a baja resolución, cargado una vez por sesión. Los tickets abiertos no se listan — son issues hijos abiertos, encontrados por consulta.
## Destino
<cómo se ve llegar al final de este mapa — la spec, decisión o cambio hacia el que este esfuerzo está encontrando su camino. Una o dos líneas; cada sesión se orienta con esto antes de elegir un ticket.>
## Notas
<dominio; skills que cada sesión debe consultar; preferencias permanentes de este esfuerzo>
## Decisiones hasta ahora
<!-- el índice — una línea por ticket cerrado: suficiente para juzgar relevancia, y luego hacer zoom al enlace para el detalle que guarda el ticket -->
- [<título del ticket cerrado>](enlace) — <resumen de una línea de la respuesta>
## Aún no especificado
<!-- ver "Niebla de guerra": niebla en alcance que aún no puede convertirse en ticket; se gradúa a medida que avanza el frontier -->
<!-- ver "Fuera de alcance": trabajo declarado más allá del destino; cerrado, nunca se gradúa -->
Cada ticket es un issue hijo del mapa; el id de issue del tracker es su identidad. Su cuerpo es la pregunta, dimensionada para una sesión de agente de 100K tokens:
## Pregunta
<la decisión o investigación que este ticket resuelve>
Cada ticket lleva una label wayfinder:<tipo> — uno de research, prototype, grilling, task (ver Tipos de tickets).
Una sesión reclama un ticket asignándolo al dev que conduce el mapa, primero, antes de cualquier trabajo, para que las sesiones concurrentes lo salten. Ese asignado es el reclamo: un ticket abierto y sin asignar está sin reclamar.
El bloqueo usa la relación de dependencia nativa del tracker — esencial porque renderiza el frontier visualmente en la propia UI del tracker, de modo que el humano ve qué es tomable sin abrir el mapa. Solo un tracker sin bloqueo nativo recurre a una convención en el cuerpo. Un ticket está desbloqueado cuando todos los tickets que lo bloquean están cerrados; el frontier son los hijos abiertos, desbloqueados y sin reclamar — el borde de lo conocido.
La respuesta no forma parte del cuerpo — se registra en la resolución (ver Recorrer el mapa). Los assets creados al resolver un ticket se enlazan desde el issue, no se pegan dentro.
Cada ticket es o bien HITL — human in the loop, trabajado con un humano que habla por sí mismo — o AFK, conducido por el agente solo. Un ticket HITL solo se resuelve mediante ese intercambio en vivo; el agente nunca suplanta el lado humano (un agente de grilling que responde sus propias preguntas ha roto esto).
/research. Usar cuando se requiera conocimiento fuera del directorio de trabajo actual.El mapa es deliberadamente incompleto: no trazar lo que aún no puedes ver. Más allá de los tickets vivos está la niebla de guerra — la vista borrosa de decisiones e investigaciones que se ve venir pero que aún no pueden fijarse, porque cuelgan de preguntas todavía abiertas. Resolver un ticket despeja la niebla que tiene delante, graduando lo que ya sea especificable en tickets frescos — de uno en uno, hasta que el camino al destino esté despejado y no queden tickets.
La sección Aún no especificado del mapa es donde se escribe esa vista borrosa: la pregunta sospechada, el área a revisitar más tarde. Es el frontier sin descubrir hacia el destino — todo lo que hay aquí está en alcance, solo que no lo bastante nítido para ser ticket. Escribir tan suelto o tan completo como permita la vista; sirve también de señal para los colaboradores que leen hacia dónde va el esfuerzo.
¿Niebla o ticket? La prueba es si puedes enunciar la pregunta con precisión ahora — no si puedes responderla ahora.
Aún no especificado excluye lo ya decidido (Decisiones hasta ahora), lo que ya es un ticket vivo, y lo que está fuera de alcance (la sección siguiente).
La niebla solo se acumula hacia el destino. El destino fija el alcance, así que el trabajo más allá de él está fuera de alcance — no es niebla, y no pertenece a Aún no especificado. Tiene su propia sección Fuera de alcance en el mapa: trabajo que has descartado conscientemente de este esfuerzo. Lo que lo trae aquí es el alcance, no la nitidez.
El trabajo fuera de alcance nunca se gradúa — el frontier se detiene en el destino — así que solo vuelve si el destino se redibuja, y entonces como un esfuerzo nuevo, no como una reanudación.
Declarar algo fuera de alcance es un acto de alcance, no un paso de la ruta. Cuando un ticket ya existente resulta quedar más allá del destino — mal incluido al trazar, o expuesto por una resolución — cerrarlo (un ticket cerrado está inequívocamente fuera del frontier) y dejar una línea en la sección Fuera de alcance: el resumen más el porqué está fuera de alcance, enlazando el ticket cerrado. Queda fuera de Decisiones hasta ahora, que registra la ruta realmente andada — un límite de alcance no es un paso de ella.
Dos modos. En cualquiera de los dos, nunca resolver más de un ticket por sesión — con la excepción de los tickets de research.
El usuario invoca con una idea suelta.
/grilling y /domain-modeling para fijar hacia qué está encontrando su camino este mapa — la spec, decisión o cambio. El destino fija el alcance, así que se acuerda primero.wayfinder:map): Destino y Notas rellenos, Decisiones-hasta-ahora vacía, la niebla esbozada en Aún no especificado.research recién creado, lanzar un subagente de /research que lo resuelva en paralelo, capturando sus hallazgos en una branch descartable research/<nombre> con un puntero de contexto desde el ticket.El usuario invoca con un mapa (URL o número). Un ticket es opcional — sin él, eliges tú la próxima decisión, no el usuario.
## Notas. En caso de duda, usar /grilling y /domain-modeling.El usuario puede ejecutar tickets desbloqueados en paralelo, así que hay que esperar que otras sesiones estén editando el tracker concurrentemente.