TL;DR: /wayfinder is a planning skill for AI agents that solves the "fog of war" problem: projects whose end state is not fully defined at the start. Instead of juggling sessions and context windows by hand, an orchestration layer takes over: it decomposes planning into partial sessions with a shared map and precise ticket types, and merges everything back into a detailed spec.
The problem: planning as the bottleneck for AFK agents
Matt Pocock, founder of aihero.dev and operator of a GitHub skills repo with over 220,000 stars, describes the typical bottleneck of his work in an interview with Latent Space: the actual execution runs almost by itself with AFK agents (Away From Keyboard) — the preceding planning does not.
- The planning session must constantly watch the context window: how many tokens are consumed, how deep has the session already gone?
- Handoffs between planning threads, prototypes, and research run manually and are error-prone.
- At the end stands a spec that is too rough for an agent to "just continue".
The approach of /wayfinder: an orchestration layer above the planning that takes over this bookkeeping.
How /wayfinder works
The mechanics reduce to three precisely named concepts — Pocock calls them "leading words", because unambiguous vocabulary stabilizes the agent's behavior:
- Map — a central document with the rough overview and all decisions made so far.
- Ticket — the concrete task for a single partial session.
- Session — the working context that receives map and ticket and works to a closable state from them.
Every child session needs exactly two things: the understanding of the whole via the map and its specific task as a ticket. A grilling session can thus manage further grilling sessions and merge the results at the end in a level of detail that a single context could not deliver.
The four ticket types
| Type | Purpose |
|---|---|
| Grilling | A planning dialog that extracts decisions |
| Prototype | Fast prototype to verify a path |
| Research | Targeted research on a sub-aspect |
| Task | Everything the human must do and the agent cannot |
This taxonomy is deliberately small. Pocock therefore uses /wayfinder not only for software: courses can be planned with it too — every structure of fuzzy goal plus partial decisions is compatible.
The core concept: fog of war
"Fog of war" means two things with Pocock: the state of a project whose end state cannot be fully defined at the start — and the limitation of individual agent contexts. /wayfinder reduces both step by step: every session lifts a piece of fog, the map records the clarity, and the next ticket generation builds on it.
The practical gain is a copyable workflow:
1. start /wayfinder, name the vague project goal
2. map emerges: frame + open questions
3. outsource open questions as grilling/research/prototype tickets
4. integrate results back into the map
5. transfer the finished spec into task tickets for AFK agents
Why the pattern holds
The skill is a textbook example of the "skills = SOPs for agents" idea: a documented, reusable procedure that replaces manual context management. Those working with Claude Code or similar harnesses can apply the three building blocks (map, ticket, session) directly to their own projects — the taxonomy is harness-neutral.
The most important lesson from the interview: precise names before clever logic. Who consistently distinguishes map, ticket, and session gets less drift in long planning threads — independent of which model runs underneath.
FAQ
Why do I need /wayfinder if I already have a spec-first workflow? The spec-first workflow assumes the end state is already known. /wayfinder is exactly for the cases before that: a vague goal, several open branches, unclear priorities. The partial sessions clarify the branches, and at the end stands the detailed spec with which the normal workflow continues.
What is the difference between map and ticket? The map is the overarching document: overview, context, all decisions made so far. The ticket is the single, closable task of a session. This separation prevents every child session from having to re-"guess" the complete history.
Why are own ticket types like Grilling and Prototype sensible? Because every type has a different ending: Grilling ends with a decision, Prototype with a verified path, Research with an answer, Task with a done checkmark. The agent recognizes from the type which output form is requested — that reduces follow-up questions and wrong outputs.
Can the principle be rebuilt without Pocock's repo? Yes, the mechanics are deliberately simple: a map document, numbered tickets, clear naming per layer. Pocock's repo at github.com/mattpocock/skills delivers the finished template, but the model behind it (leading words plus information flow) transfers into every harness with text files.
For which project sizes does the skill pay off most? Strongest for medium to large undertakings with several partial decisions — greenfield projects, course formats, migration-heavy refactors. For one-sentence specs without open branches the overhead is unnecessary; then the direct path from spec to task suffices.