Ein Plandokument ist das falsche Artefakt für KI-Arbeit, die mehrere Sitzungen umspannt. Ich habe das auf die teure Art gelernt: Die Argumentation, die einen Plan erzeugt hat, lebt im Gespräch, und das Gespräch stirbt, wenn die Sitzung endet. Die nächste Sitzung liest dein schönes Markdown-Plan und baut selbstbewusst eine Annahme wieder auf, die du vor zwei Tagen bereits verworfen hattest. Die Wayfinder-Skill, aus Matt Pococks Engineering-Skills-Pack, ist das erste Tool, das ich gesehen habe, das dies als Kernproblem behandelt statt als Fußnote.
Ich nutze Claude Code täglich über eine Laravel-Monorepo, Kundenbuilds und Content-Pipelines, und fast alles, was es wert ist getan zu werden, ist größer als eine Sitzung. Hier ist, wie Wayfinder tatsächlich funktioniert, was mein eigener Multi-Sitzungs-Workflow mich lehrte, bevor ich es fand, und die spezifischen Fälle, in denen danach zu greifen ein Fehler ist.
Was ein Multi-Sitzungs-Projekt mich lehrte, bevor Wayfinder existierte
Letzten Monat schrieb ich 84 Blogposts auf dieser Seite in sieben Batches und mehr als einem Dutzend Claude-Code-Sitzungen um. Was es vor dem Zusammenbruch bewahrte, war kein Plandokument. Es war eine dumme kleine Datei namens REWRITE-STATUS.json — ein Manifest, das jede Post-ID mit einem DONE- oder PENDING-Flag auflistete, aktualisiert durch ein mark_done.php-Skript, nachdem jeder Batch angewendet und verifiziert wurde.
Jede frische Sitzung konnte dieses Manifest in zwei Sekunden lesen und genau wissen, wo das Projekt stand. Kein Zusammenfassen des vorherigen Gesprächs, keine Herleitung des Status aus der Git-Geschichte. Das Manifest war das Gedächtnis des Projekts; die Sitzungen waren Wegwerfware.
Aber ein Manifest verfolgt nur Arbeit. Es kann einer neuen Sitzung nicht sagen, warum Batch drei die Linkformate wechselte, oder warum wir aufhörten, einer Kategorie von Quellen zu vertrauen. Das waren Entscheidungen, ausgetragen in Gesprächen, die nicht mehr existieren. Diese Lücke — dauerhafte Entscheidungen, nicht nur dauerhafter Status — ist genau das, was Wayfinder füllt.
Was die Wayfinder-Skill tatsächlich tut
Wayfinder bildet eine große Anstrengung als eine Karte von Entscheidungstickets auf dem Issue-Tracker deines Repos ab und löst sie eines nach dem anderen über so viele Sitzungen wie nötig auf. Zwei Ideen machen es funktionsfähig:
Das Ticket ist eine Frage, keine Aufgabe. Ein Wayfinder-Ticket ist nie „baue den Anteilsberechnungsmotor." Es ist „wie gehen wir mit Planwechseln mitten im Zyklus um, wenn der Kunde ungenutztes Guthaben hat?" Ein Ticket auflösen produziert eine Entscheidung, permanent auf dem Ticket festgehalten. Es ist kein Teil des Builds.
Die Karte ist ein Index, kein Speicher. Die Karte ist ein einzelnes Issue mit dem Label wayfinder:map. Kind-Issues sind die Tickets. Jede Entscheidung lebt an genau einem Ort — ihrem eigenen Ticket — und die Karte fasst sie nur zusammen und verlinkt darauf. Keine doppelten Kopien, die auseinanderdriften.
Das Map-Issue enthält fünf Abschnitte: Destination (ein oder zwei Zeilen, die den Endpunkt benennen), Notes (Domänenkontext, den jede Sitzung braucht), Decisions so far (geschlossene Tickets, zusammengefasst und verlinkt), Not yet specified (der Nebel) und Out of scope (Arbeit, die explizit ausgeschlossen wurde).
Die Destination-Zeile leistet mehr Arbeit als es aussieht. Mach sie vage und jedes nachgelagerte Ticket erbt die Vagheit.
Fog of War: der Test, der überall übertragbar ist
Wayfinder leiht das Strategiespielkonzept Fog of War. Deine Tickets sind der beleuchtete Bereich — Fragen, die du heute präzise formulieren kannst. Dahinter ist Nebel: „da ist etwas mit Steuerjurisdiktionen, ich kann es noch nicht formulieren." Du planst keine Route durch Nebel. Du rückst zur Grenze vor, enthüllst mehr Terrain, dann entscheidest du.
Der Test für Nebel versus Ticket ist stumpf: Kannst du die Frage jetzt präzise formulieren? Ja bedeutet Ticket. Nein bedeutet Nebel.
Ich wende diesen Test jetzt außerhalb von Wayfinder an. Die Hälfte der Tickets, die ich für Kundenprojekte schrieb, waren Nebel im Ticketkostüm — vage genug, dass wer sie aufnahm die erste Stunde damit verbrachte herauszufinden, was die Frage überhaupt war.
Zwei weitere Begriffe sind wichtig. Die Frontier ist die Menge der offenen, nicht-blockierten, nicht-beanspruchten Tickets — Entscheidungen, die gerade tatsächlich getroffen werden können. Claimen bedeutet, ein Ticket sich selbst zuzuweisen, bevor man daran arbeitet, damit zwei parallele Sitzungen nicht dieselbe Frage auf zwei verschiedene Arten lösen. Ich nutze parallele Agents über Git-Worktrees ständig, und der wiederkehrende Fehler ist genau das: zwei Agents, die inkompatible Entscheidungen in denselben zwanzig Minuten treffen.
Die vier Tickettypen, und der eine, der schiefgeht
Jedes Ticket trägt ein Typ-Label, das bestimmt, welche Skill es auflöst und ob du im Stuhl sitzen musst:
| Typ | Modus | Was es auflöst |
|---|---|---|
grilling |
Mensch in der Schleife | Fragen, die durch Gespräch geklärt werden — der Standard |
prototype |
Mensch in der Schleife | Verhaltens- oder ästhetische Fragen, die ein echtes Artefakt brauchen |
research |
Agent arbeitet allein | Externe Fakten, die eine Entscheidung blockieren; läuft parallel |
task |
Beides | Manuelle Voraussetzungen, die eine Entscheidung freischalten |
Grilling ist das Arbeitspferd — ein adversariales Q&A, das auf deinen Plan drückt, bis der Zweig sich auflöst. Ich habe grill-me und grill-with-docs aus demselben Pack auf dieser Maschine installiert und nutze sie wöchentlich; grill-with-docs aktualisiert auch CONTEXT.md und ADRs, wenn Entscheidungen kristallisieren, was genau das ist, was ein Entscheidungsticket füttern sollte.
Research verändert die Ökonomie. Diese feuern als Subagents, parallel, während du woanders bist. Vier Research-Tickets lösen sich in der Zeit auf, die eine Grilling-Sitzung dauert.
Prototype existiert, weil manche Fragen nicht in Prosa beantwortet werden können. „Wizard oder einzelnes Formular?" wird durch ein Wegwerf-Artefakt geklärt — keine Tests, keine Abstraktionen, gelöscht sobald es die Frage beantwortet hat.
Task ist der Typ, der am häufigsten schiefgeht, und die eigene Dokumentation der Skill gibt es zu. Ein Task-Ticket ist manuelle Arbeit, die eine Entscheidung freischaltet — die Staging-Datenbank einrichten, API-Credentials beschaffen. Agents interpretieren es konsequent als Implementierungsschritt um und beginnen Produktionscode innerhalb der Planungsgrenze zu schreiben. Beobachte deine task-Tickets.
Wie ein Durchlauf verläuft, Sitzung für Sitzung
Sitzung eins: Kartierung. Du kommst mit einer vagen Bestimmung — „stelle Abrechnung auf nutzungsbasiert um in diesem Quartal." Der Agent grillt dich, bis die Destination ein oder zwei konkrete Zeilen ist, kartiert die Frontier breadth-first (depth-first Kartierung zieht dich einen Zweig hinab, bis ein Nachbarzweig ihn ungültig macht), erstellt das Map-Issue und die Tickets, die du heute formulieren kannst, verdrahtet echte Blockierungskanten zwischen ihnen, legt den Rest in den Nebel und feuert die Research-Subagents ab. Dann stoppt es. Kartierung ist eine Sitzung.
Sitzungen zwei bis N: die Karte abarbeiten. Jede Sitzung lädt die Karte in niedriger Auflösung — Destination, Notes, Decisions so far, Frontier — nicht jeden Ticket-Body. Du claimst ein Frontier-Ticket. Der Agent löst es mit der passenden Skill auf, postet die Lösung als Kommentar, schließt das Ticket, fasst es in Decisions so far zusammen, erstellt eventuelle Tickets, die die Lösung aufgedeckt hat, befördert Nebel, der jetzt scharf genug ist, um formuliert zu werden. Und es stoppt.
Dieses „und es stoppt" trägt das gesamte System. Eine Entscheidung pro Sitzung bedeutet, dass jede Entscheidung ein frisches Kontextfenster an Urteilsvermögen bekommt. Sitzungen, die weitermachen, treffen drei Entscheidungen auf einem Fenster, das nur noch gutes Urteilsvermögen für eine hatte. Dies ist dieselbe Disziplin, die mein Umschreib-Manifest zufällig erzwang: kleine, verifizierte Inkremente, Status aufgeschrieben, Sitzung verworfen.
Die Karte löst sich auf. Irgendwann leert sich die Frontier und der Nebel ist verschwunden. Was du hast, ist ein Netz verlinkter Entscheidungen mit den Argumenten intakt — kein Buildplan. Der letzte Schritt konvertiert es: im aktuellen Release des Packs wandelt /to-spec die Entscheidungen in eine Spezifikation um und /to-tickets schneidet diese in Implementierungsarbeit. Meine eigene Installation zeigt noch die älteren /to-prd und /to-issues in ~/.claude/skills/, was mir klar sagt, dass mein Pack von vor dieser Umbenennung stammt — es lohnt sich zu prüfen, welches Paar du hast, bevor du annimmst, dass Wayfinder installiert ist.
Setup ist ein Durchgang: installiere das Pack aus dem mattpocock/skills Repo oder dem Claude Code Plugin Marketplace, dann führe /setup-matt-pocock-skills einmal pro Repo aus. Es registriert, welchen Issue-Tracker das Repo nutzt (GitHub via gh, GitLab via glab, lokales Markdown für Repos ohne Remote, oder eine Prosabeschreibung deines Jira/Linear-Workflows), deine Triage-Labels und wo Domänen-Docs leben. Diese Prosa-Option ist, warum die Bezeichnung tracker-agnostisch fair ist: es liefert keine Jira-Integration, es liefert einen Ort, um aufzuschreiben, wie dein Tracker funktioniert.
Eine Designentscheidung, die es wert ist, hervorgehoben zu werden: Blockierungsbeziehungen nutzen die nativen Abhängigkeitsfunktionen des Trackers, nie eine Konvention im Issue-Body. Wenn „Blocked by: #42" Text in einer Beschreibung ist, versteht es nur der Agent, der es geschrieben hat. Wenn es eine echte Blockierungskante ist, rendert GitHub den Abhängigkeitsgraph und die Frontier wird etwas, das du sehen kannst.
Wie es sich von spec-getriebener Entwicklung unterscheidet
Spec-getriebene Frameworks — Spec Kit, Kiro, OpenSpec, das ich eine Weile täglich nutzte — behandeln die Spec als die persistente Quelle der Wahrheit. Wayfinder sitzt stromaufwärts von allen: es ist, was du startest, wenn es zu viel Nebel gibt, um überhaupt eine Spec zu schreiben. Und seine Spec-Ausgabe ist bewusst Wegwerfware — ein Meilenstein, kein gepflegtes Dokument.
Das ist die Inversion, die es wert ist behalten zu werden: traditionelle spec-getriebene Entwicklung sagt, das Dokument ist permanent und die Argumentation ist Wegwerfware. Wayfinder sagt, die Argumentation ist permanent und das Dokument ist Wegwerfware. Nachdem ich gesehen habe, was mit Spec-Dokumenten nach sechs Monaten passiert, denke ich, dass Wayfinder es richtig herum hat.
Wann ich nicht danach greifen würde
Planung passt in eine Sitzung. Die meiste Arbeit qualifiziert sich. Nutze /grill-with-docs und sei in vierzig Minuten fertig; eine Karte, vier Tickettypen und Claim-Konventionen sind reiner Overhead für ein abgegrenztes Feature.
Die Route ist klar und nur die Arbeit ist groß. Groß ist nicht der Auslöser — neblig ist es. Mein Umschreiben von 84 Posts war groß, aber nie neblig; ein Manifest und Batch-Disziplin deckten es ab. Eine zwölfwöchige Migration, bei der du jeden Schritt kennst, braucht parallele Implementierungs-Agents, keine Kartierung.
Du hast keinen Tracker, den du tatsächlich nutzt. Der lokale-Markdown-Fallback funktioniert, aber du verlierst native Blockierungskanten und die sichtbare Frontier, was den Großteil des mechanischen Werts ausmacht.
Du findest adversariales Q&A ermüdend. Das Grilling ist erschöpfend — jede Frage kommt als drei Absätze. Eine CLAUDE.md-Anweisung, eine kurze Frage pro Mal zu stellen, hilft, behebt es aber nicht vollständig. Rechne damit, bevor du eine Karte mit zwanzig Tickets kartierst.
Für Sitzung-zu-Sitzung-Kontinuität bei Arbeit, die keine vollständige Entscheidungskarte braucht, ist die Handoff-Skill das leichtere Werkzeug, und nichts davon ersetzt grundlegendes Kontextmanagement bei langen Sitzungen — ein größeres Fenster kauft Raum, keine Kontinuität.
Die Neurahmung, die ich in jedem Fall behalte: Hör auf Pläne zu schreiben, fang an Fragen zu schließen. Ein Plan ist eine Behauptung über eine Zukunft, die du nicht sehen kannst. Ein geschlossenes Entscheidungsticket ist ein Fakt mit dem Argument daran befestigt, und es überlebt jeden Kontextreset. Öffne das Plandokument deines aktuellen Projekts und zähle, welche Zeilen Entscheidungen mit Argumentation dahinter sind und welche Vermutungen in einer selbstbewussten Stimme sind. Die Vermutungen sind dein Nebel — und jetzt weißt du, wie viel der Karte du nie kartiert hast.
Wayfinder ist eine von Dutzenden Skills, die ich gegen echte Projektarbeit geprüft habe. Wenn du entscheidest, welche einen Platz in deinem eigenen Setup verdienen, ist mein Agent Skills Marketplace wo ich diejenigen aufbewahre, die ihren Platz verdient haben.
