---
type: "BlogPosting"
title: "Navigating the Fog of War: Matt Pocock's /wayfinder skill"
description: "Matt Pocock's /wayfinder skill solves the fog-of-war problem of AI planning: an orchestration layer of map, ticket, and session that merges partial sessions into a detailed spec."
resource: "https://www.contextstudios.ai/blog/navigating-the-fog-of-war-matt-pocock-s-wayfinder-skill-2"
language: "en"
tags: ["AI Agents", "Context Engineering", "Developer Tools", "Matt Pocock", "Claude Code"]
generated:
  by: "process:contextstudios-md/1"
  at: "2026-10-05T10:22:49.183Z"
status: "stable"
---

# Navigating the Fog of War: Matt Pocock's /wayfinder skill

Published: 2026-09-14
Tags: AI Agents, 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 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](http://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:

1. **Map** — a central document with the rough overview and all decisions made so far.
2. **Ticket** — the concrete task for a single partial session.
3. **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](http://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.

## Sources

- [The /wayfinder Skill: Navigating the "Fog of War" of Planning — Latent Space](https://www.latent.space/p/wayfinder-skill)
- [/wayfinder on aihero.dev](https://www.aihero.dev/skills-wayfinder)
- [AI Skills for Real Engineers — aihero.dev](https://www.aihero.dev/skills)
- [mattpocock/skills on GitHub](https://github.com/mattpocock/skills)
- [Matt Pocock on YouTube](https://www.youtube.com/@mattpocockuk)

## Related

- [AI Agent Development](https://www.contextstudios.ai/ai-agent-development.md)
- [AI Development](https://www.contextstudios.ai/ai-development.md)
- [Multi-Agent Systems](https://www.contextstudios.ai/multi-agent-systems.md)
- [AI Agency](https://www.contextstudios.ai/ai-development-company.md)