Wayfinder Skill : Planifiez du Travail IA Multi-Sessions

Un document de plan est le mauvais artefact pour du travail IA qui s'étend sur plusieurs sessions. J'ai appris cela à mes dépens : le raisonnement qui a produit un plan vit dans la conversation, et la conversation meurt quand la session se termine. La session suivante lit votre beau plan en markdown et reconstruit avec assurance une hypothèse que vous aviez déjà écartée deux jours plus tôt. La skill Wayfinder, du pack d'engineering skills de Matt Pocock, est le premier outil que j'ai vu qui traite cela comme le problème central plutôt qu'une note de bas de page.

J'utilise Claude Code quotidiennement sur une monorepo Laravel, des builds clients et des pipelines de contenu, et presque tout ce qui vaut la peine d'être fait est plus grand qu'une session. Voici comment Wayfinder fonctionne réellement, ce que mon propre workflow multi-sessions m'a appris avant de le trouver, et les cas spécifiques où y recourir est une erreur.

Ce qu'un projet multi-sessions m'a appris avant que Wayfinder existe

Le mois dernier, j'ai réécrit 84 articles de blog sur ce site en sept lots et plus d'une douzaine de sessions Claude Code. Ce qui a empêché l'effondrement n'était pas un document de plan. C'était un petit fichier bête appelé REWRITE-STATUS.json — un manifeste listant chaque ID de post avec un drapeau DONE ou PENDING, mis à jour par un script mark_done.php après l'application et la vérification de chaque lot.

N'importe quelle session fraîche pouvait lire ce manifeste en deux secondes et savoir exactement où en était le projet. Pas de résumé de la conversation précédente, pas de redérivation de l'état depuis l'historique git. Le manifeste était la mémoire du projet ; les sessions étaient jetables.

Mais un manifeste ne suit que le travail. Il ne peut pas dire à une nouvelle session pourquoi le lot trois a changé de format de liens, ou pourquoi nous avons arrêté de faire confiance à une catégorie de sources. C'étaient des décisions, débattues dans des conversations qui n'existent plus. Cette lacune — des décisions durables, pas seulement un statut durable — est précisément ce que Wayfinder comble.

Ce que la skill Wayfinder fait réellement

Wayfinder cartographie un gros effort comme une carte de tickets de décision sur l'issue tracker de votre repo, puis les résout un par un sur autant de sessions que nécessaire. Deux idées le font fonctionner :

Le ticket est une question, pas une tâche. Un ticket Wayfinder n'est jamais « construis le moteur de prorata. » C'est « comment gérons-nous les changements de plan en cours de cycle quand le client a du crédit inutilisé ? » Résoudre un ticket produit une décision, enregistrée de façon permanente sur le ticket. Ce n'est pas une tranche du build.

La carte est un index, pas un stockage. La carte est une seule issue étiquetée wayfinder:map. Les issues enfants sont les tickets. Chaque décision vit à exactement un endroit — son propre ticket — et la carte ne fait que la résumer et y lier. Pas de copies dupliquées qui dérivent.

L'issue de la carte comporte cinq sections : Destination (une ou deux lignes nommant le point d'arrivée), Notes (contexte du domaine dont chaque session a besoin), Decisions so far (tickets fermés, résumés et liés), Not yet specified (le brouillard), et Out of scope (travail explicitement exclu).

La ligne Destination fait plus de travail qu'il n'y paraît. Rendez-la vague et chaque ticket en aval hérite de l'imprécision.

Fog of war : le test qui se transfère partout

Wayfinder emprunte le concept de fog of war des jeux de stratégie. Vos tickets sont la zone éclairée — des questions que vous pouvez formuler précisément aujourd'hui. Au-delà, c'est le brouillard : « il y a quelque chose sur les juridictions fiscales ici, je ne peux pas encore le formuler. » Vous ne planifiez pas un itinéraire à travers le brouillard. Vous avancez jusqu'à la frontière, révélez plus de terrain, puis décidez.

Le test brouillard versus ticket est direct : pouvez-vous formuler la question précisément, maintenant ? Oui signifie ticket. Non signifie brouillard.

J'applique maintenant ce test en dehors de Wayfinder entièrement. La moitié des tickets que j'écrivais pour les projets clients étaient du brouillard déguisé en ticket — assez vagues pour que celui qui les prenait passe la première heure à redériver quelle était la question.

Deux autres termes comptent. La frontier est l'ensemble des tickets ouverts, non bloqués, non revendiqués — des décisions réellement prenables maintenant. Revendiquer signifie s'assigner un ticket avant d'y travailler, pour que deux sessions parallèles ne résolvent pas la même question de deux manières différentes. Je fais tourner des agents parallèles sur des git worktrees constamment, et l'échec récurrent est exactement cela : deux agents prenant des décisions incompatibles dans les mêmes vingt minutes.

Les quatre types de tickets, et celui qui dérape

Chaque ticket porte une étiquette de type qui détermine quelle skill le résout et si vous devez être présent :

Grilling est le cheval de bataille — un Q&A adversarial qui pousse sur votre plan jusqu'à ce que la branche se résolve. J'ai grill-me et grill-with-docs du même pack installés sur cette machine et je les utilise chaque semaine ; grill-with-docs met aussi à jour CONTEXT.md et les ADRs à mesure que les décisions cristallisent, ce qui est exactement ce qu'un ticket de décision devrait alimenter.

Research change l'économie. Ceux-ci se lancent comme des sous-agents, en parallèle, pendant que vous êtes ailleurs. Quatre tickets de research se résolvent dans le temps qu'une session de grilling prend.

Prototype existe parce que certaines questions ne peuvent pas être répondues en prose. « Wizard ou formulaire unique ? » se règle par un artefact jetable — pas de tests, pas d'abstractions, supprimé une fois qu'il a répondu à la question.

Task est le type qui dérape le plus, et la propre documentation de la skill l'admet. Un ticket task est du travail manuel qui débloque une décision — provisionner la base de données de staging, obtenir des credentials API. Les agents le réinterprètent systématiquement comme une étape d'implémentation et commencent à construire du code de production à l'intérieur du périmètre de planification. Surveillez vos tickets task.

Comment se déroule une exécution, session par session

Session un : cartographier. Vous arrivez avec une destination floue — « passer la facturation en usage-based ce trimestre. » L'agent vous grille jusqu'à ce que la Destination soit une ou deux lignes concrètes, cartographie la frontier en breadth-first (la cartographie depth-first vous entraîne dans une branche jusqu'à ce qu'une branche sœur l'invalide), crée l'issue de la carte et les tickets que vous pouvez formuler aujourd'hui, câble de vrais liens de blocage entre eux, place le reste dans le brouillard, et lance les sous-agents de research. Puis s'arrête. Cartographier, c'est une session.

Sessions deux à N : travailler la carte. Chaque session charge la carte en basse résolution — Destination, Notes, Decisions so far, frontier — pas chaque corps de ticket. Vous revendiquez un ticket de frontier. L'agent le résout avec la skill correspondante, poste la résolution en commentaire, ferme le ticket, le résume dans Decisions so far, crée les tickets que la résolution a révélés, promeut le brouillard qui est maintenant assez précis pour être formulé. Et s'arrête.

Ce « et s'arrête » porte tout le système. Une décision par session signifie que chaque décision reçoit une fenêtre de contexte fraîche de capacité de jugement. Les sessions qui continuent prennent trois décisions sur une fenêtre qui n'avait du bon jugement que pour une seule. C'est la même discipline que mon manifeste de réécriture imposait par accident : des incréments petits et vérifiés, le statut noté, la session jetée.

La carte se résout. Finalement la frontier se vide et le brouillard a disparu. Ce que vous avez est un réseau de décisions liées avec les arguments intacts — pas un plan de build. La dernière étape le convertit : dans la version actuelle du pack, /to-spec transforme les décisions en spécification et /to-tickets la découpe en travail d'implémentation. Ma propre installation montre encore les anciens /to-prd et /to-issues dans ~/.claude/skills/, ce qui me dit clairement que mon pack est antérieur à ce renommage — ça vaut la peine de vérifier quel pair vous avez avant de supposer que Wayfinder est installé.

La mise en place est un seul passage : installez le pack depuis le repo mattpocock/skills ou le marketplace de plugins Claude Code, puis exécutez /setup-matt-pocock-skills une fois par repo. Il enregistre quel issue tracker le repo utilise (GitHub via gh, GitLab via glab, markdown local pour les repos sans remote, ou une description en prose de votre workflow Jira/Linear), vos labels de triage, et où vivent les docs du domaine. Cette option prose est pourquoi le qualifier d'agnostique de tracker est juste : il ne livre pas une intégration Jira, il livre un endroit pour écrire comment votre tracker fonctionne.

Une décision de conception qui mérite d'être soulignée : les relations de blocage utilisent les fonctionnalités natives de dépendance du tracker, jamais une convention dans le corps de l'issue. Si « Blocked by: #42 » est du texte dans une description, seul l'agent qui l'a écrit le comprend. Si c'est un vrai lien de blocage, GitHub rend le graphe de dépendances et la frontier devient quelque chose que vous pouvez voir.

Comment ça diffère du développement piloté par spec

Les frameworks pilotés par spec — Spec Kit, Kiro, OpenSpec, que j'ai utilisé comme outil quotidien pendant un moment — traitent la spec comme la source de vérité persistante. Wayfinder se situe en amont de tous : c'est ce que vous lancez quand il y a trop de brouillard pour écrire une spec du tout. Et sa sortie spec est délibérément jetable — un jalon, pas un document maintenu.

C'est l'inversion qui mérite d'être retenue : le développement traditionnel piloté par spec dit que le document est permanent et le raisonnement est jetable. Wayfinder dit que le raisonnement est permanent et le document est jetable. Ayant vu ce qui arrive aux documents de spec au bout de six mois, je pense que Wayfinder a la bonne direction.

Quand je n'y recourrais pas

La planification tient en une session. La plupart du travail se qualifie. Utilisez /grill-with-docs et finissez en quarante minutes ; une carte, quatre types de tickets et des conventions de revendication sont du pur overhead pour une feature délimitée.

La route est claire et seul le travail est grand. Grand n'est pas le déclencheur — brumeux l'est. Ma réécriture de 84 posts était grande mais jamais brumeuse ; un manifeste et de la discipline de lots l'ont couverte. Une migration de douze semaines où vous connaissez chaque étape a besoin d'agents d'implémentation parallèles, pas de cartographie.

Vous n'avez pas de tracker que vous utilisez réellement. Le fallback markdown local fonctionne, mais vous perdez les liens de blocage natifs et la frontier visible, qui représentent la plus grande partie de la valeur mécanique.

Vous trouvez le Q&A adversarial épuisant. Le grilling est éreintant — chaque question arrive en trois paragraphes. Une instruction CLAUDE.md pour poser une question courte à la fois aide, mais ne résout pas complètement le problème. Budgétez ça avant de cartographier une carte de vingt tickets.

Pour la continuité session à session sur du travail qui n'a pas besoin d'une carte complète de décisions, la skill handoff est l'outil plus léger, et rien de tout cela ne remplace la gestion basique du contexte sur les longues sessions — une fenêtre plus grande achète de l'espace, pas de la continuité.

Le recadrage que je garde dans tous les cas : arrêtez d'écrire des plans, commencez à fermer des questions. Un plan est une affirmation sur un futur que vous ne pouvez pas voir. Un ticket de décision fermé est un fait avec l'argument attaché, et il survit à chaque reset de contexte. Ouvrez le document de plan de votre projet actuel et comptez quelles lignes sont des décisions avec du raisonnement derrière et quelles sont des suppositions d'une voix assurée. Les suppositions sont votre brouillard — et maintenant vous savez combien de la carte vous n'avez jamais cartographié.

Wayfinder est l'une des dizaines de skills que j'ai évaluées contre du vrai travail de projet. Si vous décidez lesquelles méritent une place dans votre propre configuration, mon agent skills marketplace est où je garde celles qui ont gagné leur place.