TL;DR: /wayfinder ist ein Planungs-Skill für KI-Agenten, der das „Nebel des Krieges“-Problem löst: Projekte, deren Endzustand am Anfang nicht vollständig feststeht. Statt Sessions und Kontextfenster manuell zu jonglieren, übernimmt eine Orchestrierungsebene: Sie zerlegt die Planung in Teil-Sessions mit einer gemeinsamen Map und präzisen Ticket-Typen und führt alles wieder zu einem detaillierten Spec zusammen.
Das Problem: Planung als Nadelöhr bei AFK-Agenten
Matt Pocock, Gründer von aihero.dev und Betreiber eines GitHub-Skills-Repos mit über 220.000 Stars, beschreibt in einem Interview mit Latent Space den typischen Engpass seiner Arbeit: Die eigentliche Ausführung läuft bei AFK-Agenten (Away From Keyboard) praktisch von selbst — die Planung davor nicht.
- Die Planungs-Session muss ständig das Kontextfenster im Blick behalten: Wie viele Tokens sind verbraucht, wie tief ist die Session bereits gegangen?
- Handoffs zwischen Planungs-Threads, Prototypen und Recherche laufen manuell und fehleranfällig.
- Am Ende steht ein Spec, der zu grob ist, damit ein Agent „einfach weitermachen“ kann.
Der Ansatz von /wayfinder: Eine Orchestrierungsebene über der Planung, die diese Buchhaltung übernimmt.
Wie /wayfinder funktioniert
Die Mechanik lässt sich auf drei präzise benannte Konzepte reduzieren — Pocock nennt sie „leading words“, weil eindeutige Vokabeln das Verhalten des Agenten stabilisieren:
- Map — ein zentrales Dokument mit dem groben Überblick und allen bisher getroffenen Entscheidungen.
- Ticket — die konkrete Aufgabe für eine einzelne Teil-Session.
- Session — der Arbeitskontext, der Map und Ticket erhält und daraus abschließbar arbeitet.
Jede Kind-Session braucht genau zwei Dinge: das Verständnis des großen Ganzen über die Map und ihre spezifische Aufgabe als Ticket. Ein „Grilling“-Session kann so weitere Grilling-Sessions verwalten und am Ende die Ergebnisse in einem Detailgrad zusammenführen, den ein einzelner Kontext nicht leisten würde.
Die vier Ticket-Typen
| Typ | Zweck |
|---|---|
| Grilling | Ein Planungs-Dialog, der Entscheidungen herausarbeitet |
| Prototype | Schneller Prototyp zur Verifikation eines Wegs |
| Research | Gezielte Recherche zu einem Teilaspekt |
| Task | Alles, was der Mensch tun muss und der Agent nicht kann |
Diese Taxonomie ist bewusst klein. Pocock nutzt /wayfinder dadurch nicht nur für Software: Damit lassen sich auch Kurse planen — jede Struktur aus unscharfem Ziel plus Teilentscheidungen ist kompatibel.
Das Kernkonzept: Fog of War
„Nebel des Krieges“ meint bei Pocock zweierlei: den Zustand eines Projekts, dessen Endzustand man am Anfang nicht komplett festlegen kann — und die Begrenztheit einzelner Agent-Kontexte. /wayfinder reduziert beides schrittweise: Jede Session lüftet ein Stück Nebel, die Map hält die Klarheit fest, und die nächste Ticket-Generation baut darauf auf.
Der praktische Gewinn ist ein kopierbarer Workflow:
1. /wayfinder starten, vages Projektziel nennen
2. Map entsteht: Rahmen + offene Fragen
3. Offene Fragen als Grilling-/Research-/Prototype-Tickets auslagern
4. Ergebnisse zurück in die Map integrieren
5. Fertigen Spec in Task-Tickets für AFK-Agenten überführen
Warum das Muster trägt
Der Skill ist ein Musterbeispiel für die „Skills = SOPs für Agents“-Idee: Eine dokumentierte, wiederverwendbare Vorgehensweise, die das Kontext-Management von Hand ersetzt. Wer mit Claude Code oder ähnlichen Harnesses arbeitet, kann die drei Bausteine (Map, Ticket, Session) direkt auf eigene Projekte anwenden — die Taxonomie ist harness-neutral.
Die wichtigste Lehre aus dem Interview: Präzise Namen vor cleverer Logik. Wer Map, Ticket und Session konsequent unterscheidet, bekommt weniger Drift in langen Planungs-Threads — unabhängig davon, welches Modell darunter läuft.
FAQ
Wofür brauche ich /wayfinder, wenn ich schon einen Spec-First-Workflow habe? Der Spec-First-Workflow setzt voraus, dass der Endzustand bereits bekannt ist. /wayfinder ist genau für die Fälle davor: ein vages Ziel, mehrere offene Zweige, unklare Prioritäten. Die Teil-Sessions klären die Zweige, und am Ende steht der detaillierte Spec, mit dem der normale Workflow weiterarbeitet.
Was ist der Unterschied zwischen Map und Ticket? Die Map ist das übergreifende Dokument: Überblick, Kontext, alle bisher getroffenen Entscheidungen. Das Ticket ist die singuläre, abschließbare Aufgabe einer Session. Diese Trennung verhindert, dass jede Kind-Session die komplette Historie neu „erraten“ muss.
Warum sind eigene Ticket-Typen wie Grilling und Prototype sinnvoll? Weil jeder Typ ein anderes Ende hat: Grilling endet mit einer Entscheidung, Prototype mit einem verifizierten Pfad, Research mit einer Antwort, Task mit einem Erledigt-Häkchen. Der Agent erkennt am Typ, welche Ausgabeform gefragt ist — das reduziert Nachfragen und Fehlausgaben.
Lässt sich das Prinzip ohne Pococks Repo nachbauen? Ja, die Mechanik ist bewusst einfach: ein Map-Dokument, nummerierte Tickets, klare Namensgebung pro Ebene. Pococks Repo unter github.com/mattpocock/skills liefert die fertige Vorlage, aber das Modell dahinter (führende Wörter plus Informationsfluss) überträgt sich in jeden Harness mit Textdateien.
Für welche Projektgrößen lohnt sich der Skill am meisten? Am stärksten bei mittleren bis großen Vorhaben mit mehreren Teilentscheidungen — etwa Greenfield-Projekte, Kursformate, migrationslastige Refactors. Bei Ein-Satz-Specs ohne offene Zweige ist der Overhead unnötig; dann reicht der direkte Weg von Spec zu Task.