--- type: "BlogPosting" title: "Navigating the Fog of War: Matt Pocock's /wayfinder Skill" description: "Matt Pococks /wayfinder-Skill löst das „Nebel des Krieges“-Problem der KI-Planung: eine Orchestrierungsebene aus Map, Ticket und Session, die Teil-Sessions zu einem detaillierten Spec zusammenführt." resource: "https://www.contextstudios.ai/de/blog/navigating-the-fog-of-war-matt-pocock-s-wayfinder-skill" language: "de" tags: ["KI-Agenten", "Context Engineering", "Developer Tools", "Matt Pocock", "Claude Code"] generated: by: "process:contextstudios-md/1" at: "2026-10-24T15:58:40.950Z" status: "stable" --- # Navigating the Fog of War: Matt Pocock's /wayfinder Skill Published: 2026-09-11 Tags: KI-Agenten, Context Engineering, Developer Tools, Matt Pocock, Claude Code ![Navigating the Fog of War: Matt Pocock's /wayfinder Skill](https://wary-platypus-754.convex.cloud/api/storage/c4f1da15-8e3b-44eb-9208-bc384eb87afd) **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](http://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: 1. **Map** — ein zentrales Dokument mit dem groben Überblick und allen bisher getroffenen Entscheidungen. 2. **Ticket** — die konkrete Aufgabe für eine einzelne Teil-Session. 3. **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](http://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. ## Sources - [The /wayfinder Skill: Navigating the "Fog of War" of Planning — Latent Space](https://www.latent.space/p/wayfinder-skill) - [/wayfinder auf aihero.dev](https://www.aihero.dev/skills-wayfinder) - [AI Skills for Real Engineers — aihero.dev](https://www.aihero.dev/skills) - [mattpocock/skills auf GitHub](https://github.com/mattpocock/skills) - [Matt Pocock auf YouTube](https://www.youtube.com/@mattpocockuk) ## Related - [KI-Agent-Entwicklung](https://www.contextstudios.ai/de/ki-agent-entwicklung.md) - [KI-Entwicklung](https://www.contextstudios.ai/de/ki-entwicklung.md) - [Multi-Agent-Systeme](https://www.contextstudios.ai/de/multi-agent-systeme.md) - [KI-Beratung](https://www.contextstudios.ai/de/ki-beratung.md)