Een plandocument is het verkeerde artefact voor AI-werk dat meerdere sessies overspant. Ik leerde dit op de dure manier: de redenering die een plan produceerde leeft in het gesprek, en het gesprek sterft wanneer de sessie eindigt. De volgende sessie leest je prachtige markdown-plan en herbouwt vol vertrouwen een aanname die je twee dagen geleden al had verworpen. De Wayfinder-skill, uit Matt Pocock's engineering skills pack, is de eerste tool die ik heb gezien die dit als het kernprobleem behandelt in plaats van een voetnoot.
Ik draai Claude Code dagelijks over een Laravel-monorepo, klantbuilds en contentpipelines, en vrijwel alles dat de moeite waard is om te doen is groter dan één sessie. Hier is hoe Wayfinder daadwerkelijk werkt, wat mijn eigen multi-sessie workflow me leerde voordat ik het vond, en de specifieke gevallen waarin ernaar grijpen een fout is.
Wat een multi-sessie project me leerde voordat Wayfinder bestond
Afgelopen maand herschreef ik 84 blogposts op deze site in zeven batches en meer dan een dozijn Claude Code-sessies. Het enige dat het van instorten behoed was geen plandocument. Het was een dom bestandje genaamd REWRITE-STATUS.json — een manifest dat elke post-ID opsomt met een DONE of PENDING vlag, bijgewerkt door een mark_done.php script nadat elke batch was toegepast en geverifieerd.
Elke nieuwe sessie kon dat manifest in twee seconden lezen en precies weten waar het project stond. Geen samenvatting van het vorige gesprek, geen herleiding van status uit git-geschiedenis. Het manifest was het geheugen van het project; de sessies waren wegwerpbaar.
Maar een manifest volgt alleen werk. Het kan een nieuwe sessie niet vertellen waarom batch drie van linkformaat wisselde, of waarom we stopten met het vertrouwen van een categorie bronnen. Dat waren beslissingen, beargumenteerd in gesprekken die niet meer bestaan. Die kloof — duurzame beslissingen, niet alleen duurzame status — is precies wat Wayfinder opvult.
Wat de Wayfinder-skill daadwerkelijk doet
Wayfinder brengt een grote inspanning in kaart als een map van beslissingstickets op de issue-tracker van je repo, en lost ze één voor één op over zoveel sessies als nodig. Twee ideeën maken het werkend:
Het ticket is een vraag, geen taak. Een Wayfinder-ticket is nooit "bouw de proratierekening." Het is "hoe gaan we om met tussentijdse planwijzigingen wanneer de klant ongebruikt tegoed heeft?" Een ticket oplossen produceert een beslissing, permanent vastgelegd op het ticket. Het is geen deel van de build.
De map is een index, geen opslagplaats. De map is één issue gelabeld wayfinder:map. Child-issues zijn de tickets. Elke beslissing leeft op exact één plek — zijn eigen ticket — en de map vat het alleen samen en linkt ernaar. Geen dubbele kopieën die uit elkaar drijven.
De map-issue bevat vijf secties: Destination (één of twee regels die het eindpunt benoemen), Notes (domeincontext die elke sessie nodig heeft), Decisions so far (gesloten tickets, samengevat en gelinkt), Not yet specified (de mist), en Out of scope (werk dat expliciet is uitgesloten).
De Destination-regel doet meer werk dan het lijkt. Maak het vaag en elk downstream ticket erft de vaagheid.
Fog of war: de test die overal toepasbaar is
Wayfinder leent het strategiespelconcept fog of war. Je tickets zijn het verlichte gebied — vragen die je vandaag precies kunt formuleren. Daarbuiten is mist: "er is iets met belastingjurisdicties hier, ik kan het nog niet formuleren." Je plant geen route door mist. Je gaat naar de grens, onthult meer terrein, en beslist dan.
De test voor mist versus ticket is bot: kun je de vraag nu precies formuleren? Ja betekent ticket. Nee betekent mist.
Ik pas die test nu buiten Wayfinder toe. De helft van de tickets die ik voor klantprojecten schreef waren mist in een ticketkostuum — vaag genoeg dat wie ze oppakte het eerste uur besteedde aan het herleiden van wat de vraag eigenlijk was.
Nog twee termen zijn belangrijk. De frontier is de verzameling open, niet-geblokkeerde, niet-geclaimde tickets — beslissingen die nu daadwerkelijk genomen kunnen worden. Claimen betekent een ticket aan jezelf toewijzen voordat je eraan werkt, zodat twee parallelle sessies niet dezelfde vraag op twee verschillende manieren oplossen. Ik draai parallelle agents over git-worktrees voortdurend, en de terugkerende fout is precies dat: twee agents die onverenigbare beslissingen nemen in dezelfde twintig minuten.
De vier tickettypes, en degene die misgaat
Elk ticket draagt een typelabel dat bepaalt welke skill het oplost en of je in de stoel moet zitten:
| Type | Modus | Wat het oplost |
|---|---|---|
grilling |
Mens in de loop | Vragen die door gesprek worden opgelost — de standaard |
prototype |
Mens in de loop | Gedrags- of esthetische vragen die een echt artefact nodig hebben |
research |
Agent werkt alleen | Externe feiten die een beslissing blokkeren; draait parallel |
task |
Beide | Handmatige voorwaarden die een beslissing deblokkeren |
Grilling is het werkpaard — een adversariële Q&A die op je plan duwt totdat de tak oplost. Ik heb grill-me en grill-with-docs uit hetzelfde pack geïnstalleerd op deze machine en gebruik ze wekelijks; grill-with-docs werkt ook CONTEXT.md en ADR's bij naarmate beslissingen kristalliseren, wat precies is wat een beslissingsticket zou moeten voeden.
Research verandert de economie. Deze worden als subagents afgevuurd, parallel, terwijl jij ergens anders bent. Vier research-tickets lossen op in de tijd die één grilling-sessie kost.
Prototype bestaat omdat sommige vragen niet in proza beantwoord kunnen worden. "Wizard of enkel formulier?" wordt opgelost door een wegwerpartefact — geen tests, geen abstracties, verwijderd zodra het de vraag heeft beantwoord.
Task is het type dat het vaakst misgaat, en de eigen docs van de skill geven het toe. Een task-ticket is handmatig werk dat een beslissing deblokkeert — de staging-database inrichten, API-credentials ophalen. Agents herinterpreteren het consequent als een implementatiestap en beginnen productiecode te bouwen binnen de planningsgrens. Let op je task-tickets.
Hoe een run verloopt, sessie voor sessie
Sessie één: in kaart brengen. Je komt aan met een vage bestemming — "verplaats facturering naar gebruiksgebaseerd dit kwartaal." De agent grillt je totdat de Destination één of twee concrete regels is, brengt de frontier breadth-first in kaart (depth-first in kaart brengen sleept je één tak af totdat een zijtak het ongeldig maakt), maakt de map-issue en de tickets die je vandaag kunt formuleren, legt echte blokkeringsrelaties tussen ze, plaatst de rest in mist, en vuurt de research-subagents af. Dan stopt het. In kaart brengen is één sessie.
Sessies twee tot en met N: werk de map af. Elke sessie laadt de map op lage resolutie — Destination, Notes, Decisions so far, frontier — niet elke ticket-body. Je claimt één frontier-ticket. De agent lost het op met de bijbehorende skill, plaatst de oplossing als commentaar, sluit het ticket, vat het samen in Decisions so far, maakt eventuele tickets die de oplossing aan het licht bracht, promoveert mist die nu scherp genoeg is om te formuleren. En het stopt.
Dat "en het stopt" draagt het hele systeem. Eén beslissing per sessie betekent dat elke beslissing een vers contextvenster aan beoordelingsvermogen krijgt. Sessies die doorgaan nemen drie beslissingen op een venster dat alleen nog goed beoordelingsvermogen had voor één. Dit is dezelfde discipline die mijn herschrijfmanifest per ongeluk afdwong: kleine, geverifieerde stappen, status opgeschreven, sessie weggegooid.
De map lost op. Uiteindelijk leegt de frontier en is de mist verdwenen. Wat je hebt is een web van gelinkte beslissingen met de argumenten intact — geen buildplan. De laatste stap converteert het: in de huidige release van het pack zet /to-spec de beslissingen om in een specificatie en /to-tickets snijdt die in implementatiewerk. Mijn eigen installatie toont nog de oudere /to-prd en /to-issues in ~/.claude/skills/, wat me duidelijk vertelt dat mijn pack van voor die hernoeming dateert — het is de moeite waard om te controleren welk paar je hebt voordat je aanneemt dat Wayfinder is geïnstalleerd.
Setup is één doorloop: installeer het pack vanuit de mattpocock/skills repo of de Claude Code plugin marketplace, voer dan /setup-matt-pocock-skills één keer per repo uit. Het registreert welke issue-tracker de repo gebruikt (GitHub via gh, GitLab via glab, lokale markdown voor repo's zonder remote, of een prosabeschrijving van je Jira/Linear-workflow), je triagelabels, en waar domeindocs leven. Die prosa-optie is waarom het terecht tracker-agnostisch wordt genoemd: het levert geen Jira-integratie, het levert een plek om op te schrijven hoe je tracker werkt.
Eén ontwerpbeslissing die het vermelden waard is: blokkeerrelaties gebruiken de native afhankelijkheidsfuncties van de tracker, nooit een conventie in de issue-body. Als "Blocked by: #42" tekst is in een beschrijving, begrijpt alleen de agent die het schreef het. Als het een echte blokkeringsrelatie is, rendert GitHub de afhankelijkheidsgrafiek en wordt de frontier iets dat je kunt zien.
Hoe het verschilt van spec-gedreven ontwikkeling
Spec-gedreven frameworks — Spec Kit, Kiro, OpenSpec, dat ik een periode dagelijks gebruikte — behandelen de spec als de persistente bron van waarheid. Wayfinder zit stroomopwaarts van allemaal: het is wat je draait wanneer er te veel mist is om überhaupt een spec te schrijven. En de spec-output is bewust wegwerpbaar — een mijlpaal, geen onderhouden document.
Dat is de inversie die het waard is om te onthouden: traditionele spec-gedreven ontwikkeling zegt dat het document permanent is en de redenering wegwerpbaar. Wayfinder zegt dat de redenering permanent is en het document wegwerpbaar. Gezien wat er met spec-documenten gebeurt na zes maanden, denk ik dat Wayfinder het de juiste kant op heeft.
Wanneer ik er niet naar zou grijpen
Planning past in één sessie. Het meeste werk kwalificeert. Gebruik /grill-with-docs en wees klaar in veertig minuten; een map, vier tickettypes en claimconventies zijn pure overhead voor een afgebakende feature.
De route is duidelijk en alleen het werk is groot. Groot is niet de trigger — mistig is dat. Mijn herschrijving van 84 posts was groot maar nooit mistig; een manifest en batchdiscipline dekte het. Een migratie van twaalf weken waarbij je elke stap kent heeft parallelle implementatie-agents nodig, geen in kaart brengen.
Je hebt geen tracker die je daadwerkelijk gebruikt. De lokale-markdown-terugval werkt, maar je verliest native blokkeringsrelaties en de zichtbare frontier, wat het meeste van de mechanische waarde is.
Je vindt adversariële Q&A vermoeiend. De grilling is uitputtend — elke vraag komt als drie alinea's. Een CLAUDE.md-instructie om één korte vraag per keer te stellen helpt, maar lost het niet volledig op. Reken daarmee voordat je een map van twintig tickets in kaart brengt.
Voor sessie-naar-sessie continuïteit bij werk dat geen volledige beslissingsmap nodig heeft, is de handoff-skill de lichtere tool, en niets hiervan vervangt basis contextbeheer bij lange sessies — een groter venster koopt ruimte, geen continuïteit.
De herkadering die ik hoe dan ook behoud: stop met plannen schrijven, begin met vragen afsluiten. Een plan is een claim over een toekomst die je niet kunt zien. Een gesloten beslissingsticket is een feit met het argument eraan vast, en het overleeft elke contextreset. Open het plandocument van je huidige project en tel welke regels beslissingen zijn met redenering erachter en welke gissingen zijn in een zelfverzekerde stem. De gissingen zijn je mist — en nu weet je hoeveel van de map je nooit in kaart hebt gebracht.
Wayfinder is een van tientallen skills die ik heb getoetst aan echt projectwerk. Als je aan het beslissen bent welke een plek verdienen in je eigen setup, is mijn agent skills marketplace waar ik degene bewaar die hun plek hebben verdiend.
