L'essentiel : /wayfinder est un skill de planification pour agents IA qui résout le problème du « brouillard de la guerre » : les projets dont l'état final n'est pas entièrement défini au départ. Au lieu de jongler à la main entre sessions et fenêtres de contexte, une couche d'orchestration prend en charge : elle décompose la planification en sous-sessions avec une carte commune et des types de tickets précis, puis fusionne le tout en un spec détaillé.
Le problème : la planification comme goulot d'étranglement des agents AFK
Matt Pocock, fondateur de aihero.dev et opérateur d'un repo GitHub de skills avec plus de 220 000 étoiles, décrit dans un entretien avec Latent Space le goulot typique de son travail : l'exécution tourne presque seule avec des agents AFK (Away From Keyboard) — la planification qui précède, non.
- La session de planification doit garder un œil constant sur la fenêtre de contexte : combien de tokens consommés, jusqu'où la session est-elle déjà allée ?
- Les handoffs entre fils de planification, prototypes et recherche se font à la main et sont source d'erreurs.
- Au bout, un spec trop grossier pour qu'un agent « continue simplement ».
L'approche de /wayfinder : une couche d'orchestration au-dessus de la planification qui prend cette tenue de comptes en charge.
Comment fonctionne /wayfinder
La mécanique se réduit à trois concepts nommés avec précision — Pocock les appelle des « leading words », car un vocabulaire univoque stabilise le comportement de l'agent :
- Carte (Map) — un document central avec l'aperçu grossier et toutes les décisions prises jusqu'ici.
- Ticket — la tâche concrète d'une sous-session unique.
- Session — le contexte de travail qui reçoit carte et ticket et travaille depuis eux vers une clôture.
Chaque sous-session a besoin exactement de deux choses : la compréhension de l'ensemble par la carte et sa tâche spécifique en ticket. Une session grilling peut ainsi gérer d'autres sessions grilling et fusionner à la fin les résultats dans un niveau de détail qu'un seul contexte ne produirait pas.
Les quatre types de tickets
| Type | Usage |
|---|---|
| Grilling | Un dialog de planification qui extrait les décisions |
| Prototype | Prototype rapide pour vérifier une voie |
| Research | Recherche ciblée sur un sous-aspect |
| Task | Tout ce que l'humain doit faire et l'agent ne peut pas |
Cette taxonomie est délibérément petite. Pocock n'utilise donc pas /wayfinder que pour le logiciel : des cours peuvent être planifiés avec — toute structure de but flou plus décisions partielles est compatible.
Le concept central : Fog of War
Le « brouillard de la guerre » signifie deux choses chez Pocock : l'état d'un projet dont on ne peut pas entièrement définir l'état final au départ — et la limitation des contextes d'agents individuels. /wayfinder réduit les deux pas à pas : chaque session lève un morceau de brouillard, la carte inscrit la clarté, et la génération de tickets suivante s'y appuie.
Le gain pratique est un workflow copiable :
1. lancer /wayfinder, nommer le vague objectif de projet
2. la carte émerge : cadre + questions ouvertes
3. externaliser les questions ouvertes en tickets grilling/research/prototype
4. réintégrer les résultats dans la carte
5. transférer le spec fini en tickets task pour agents AFK
Pourquoi le motif tient
Le skill est un cas d'école de l'idée « skills = SOP pour agents » : une démarche documentée, réutilisable, qui remplace la gestion manuelle du contexte. Qui travaille avec Claude Code ou des harnesses similaires peut appliquer les trois briques (carte, ticket, session) directement à ses projets — la taxonomie est neutre vis-à-vis du harness.
La leçon la plus importante de l'entretien : des noms précis avant une logique maligne. Qui distingue systématiquement carte, ticket et session obtient moins de dérive dans les longs fils de planification — indépendamment du modèle qui tourne dessous.
FAQ
Pourquoi /wayfinder si j'ai déjà un workflow spec-first ? Le workflow spec-first suppose l'état final connu. /wayfinder est exactement pour les cas d'avant : un but vague, plusieurs branches ouvertes, des priorités floues. Les sous-session éclaircissent les branches, et au bout reste le spec détaillé avec lequel le workflow normal continue.
Quelle différence entre carte et ticket ? La carte est le document transversal : aperçu, contexte, toutes les décisions prises jusqu'ici. Le ticket est la tâche singulière et clôturable d'une session. Cette séparation évite que chaque sous-session doive re-« deviner » toute l'historique.
Pourquoi des types de tickets propres comme Grilling et Prototype sont-ils sensés ? Parce que chaque type a une fin différente : Grilling finit par une décision, Prototype par une voie vérifiée, Research par une réponse, Task par une coche. L'agent reconnaît au type quelle forme de sortie est demandée — cela réduit les relances et les sorties erronées.
Peut-on reconstruire le principe sans le repo de Pocock ? Oui, la mécanique est délibérément simple : un document carte, des tickets numérotés, un nommage clair par niveau. Le repo de Pocock sur github.com/mattpocock/skills fournit le modèle prêt, mais le modèle derrière (mots directeurs plus flux d'information) se transfère dans tout harness à fichiers texte.
Pour quelles tailles de projet le skill paie-t-il le plus ? Le plus fort pour les projets moyens à grands avec plusieurs décisions partielles — projets greenfield, formats de cours, refactors lourds en migrations. Pour des specs d'une phrase sans branches ouvertes, l'overhead est inutile ; le chemin direct de spec à task suffit.