English static mirror for SEO/GEO · AI-assisted translation · Read Chinese original

Wayfinder: Planning Decisions, Not Tasks (Fog of War, Decision Tickets, and Multi-Session Maps)

Forum topic · 小凯 · 2026-08-29

Summary

Wayfinder, a planning skill by Matt Pocock (creator of the widely-starred mattpocock/skills repository, released with skills v1.1), reframes planning for AI agent workflows: the unit of planning is not the task but the unresolved decision. Its core mechanism, "decision tickets," are questions whose resolution yields a decision rather than a slice of build work. Tickets come in four types — research (AFK, run by subagents), prototype (human-in-the-loop), grilling (human conversation, the default), and task (the only execution type, which must unlock a decision). An explicit "fog of war" principle forbids pre-slicing unknowns into tickets; unresolved questions stay in fog until an earlier ticket "graduates" them. Coordination across many concurrent agent sessions piggybacks on native issue-tracker features: assignees act as locks, blocking edges visualize dependencies, and the "frontier" marks open, unblocked, unclaimed work. The analysis argues Wayfinder collapses the definition-side cost of large fuzzy projects, notes the map's "index, not store" interface discipline, and highlights its deepest flaw: the "plan, don't do" constraint lives in a file the agent itself wrote, making it advisory rather than enforced. Community verdict: don't use it if the work fits one session.

"Nothing is too big to plan anymore" — the real claim behind the slogan is sharper than the clickbait version. It converges on one sentence: when the volume of unresolved decisions in a piece of work exceeds what a single agent session can reliably hold, you need a coordination mechanism. The binding constraint is not project size; it is total uncertainty ÷ session window.

Some context on the author: Matt Pocock, a top figure in TypeScript education (creator of aihero.dev, 347K YouTube subscribers). His mattpocock/skills repository sits at 240K stars (verified via GitHub API; it was 220K when Latent Space covered it on August 20). Wayfinder shipped with skills v1.1 (July 2026), in the same release that upgraded to-prd/to-issues into to-spec/to-tickets.

1. The Core Reframe: Decision Tickets, Not Task Slices

The SKILL.md opening definition is precise: decision tickets are "questions whose resolution is a decision, not slices of a build to execute" — resolving one yields a decision, not an executable chunk of work. This single line is the watershed separating Wayfinder from every traditional planning method:

| | Traditional WBS / todo | Spec-first (PRD) | Single-session grilling | Wayfinder | |---|---|---|---|---| | Object of planning | Task slices | Full spec | Decisions resolvable on the spot | All unresolved decisions | | Attitude toward the unknown | Pretends omniscience, slices to the bottom | Risk register (side attachment) | Anything unresolvable in talk gets dropped | Fog is a first-class citizen | | Carrier | Document | Document | Session history | A map on the issue tracker | | Session count | — (humans read docs) | 1 | 1 | N, concurrent | | Output | Task list | Spec | Decision records | Decision map → to-spec collapses into a spec |

Four ticket types map to four cognitive actions: research (AFK — subagents fan out in parallel for facts outside the working directory), prototype (HITL — when conversation can't settle look/feel, build a cheap rough artifact to react to), grilling (HITL, the default — talk it out; "the agent answering its own grilling questions = broken ticket"), and task (the only type that "does" rather than "decides," and it must exist in the name of unlocking some decision). The HITL/AFK split is a hard boundary: humans appear only when talking and looking at prototypes; research and drudgery go to machines — the cleanest landing yet of verification-bandwidth economics.

2. Fog of War: Mechanizing "Knowing What You Don't Know"

Fog of war (Warcraft III-style exploration fog) is not rhetoric; it is an operational criterion. The fog-vs-ticket test is one question only: can you currently state this problem precisely (not whether you can answer it). If you can state it → open a ticket. If you can't → it stays in fog, and pre-slicing the fog into ticket-sized chunks is forbidden — because resolving one ticket illuminates what lies ahead, letting fog "graduate" into new tickets; pre-cut chunks are guesses about terrain made before illumination. Resolving a ticket has three side effects: graduating fog, marking adjacent territory out of scope, and invalidating other tickets. Fog only condenses toward the destination — that's the orthogonality of scope and sharpness: things outside the boundary can be perfectly clear, but clear is not the same as on-route.

The map itself is a textbook case of interface discipline: index, not store — each decision lives only in its own ticket; the map holds a gist plus links; sessions load the whole map at low resolution and zoom into individual tickets on demand. Four sections: Destination (a named first action that anchors the scope yardstick for every ticket) / Decisions so far / Not yet specified (the fog) / Out of scope.

Multi-session coordination uses three distributed-systems classics, all parasitic on native issue-tracker capabilities: assignee as lock (claim before working; concurrent sessions skip claimed tickets), native blocking edges (the dependency graph is visualized directly in the tracker UI), and frontier (open + unblocked + unclaimed = the executable edge). Ticket size is measured honestly: one per 100K-token session.

Editorial Observations

One: the "task-definition cost collapse" axis gains its planning-side node. The main axis (teleoperation → simulation → bootstrapping → deployment collapse) describes four stages of falling execution-side cost; Wayfinder compresses the definition side — the definition work for "large fuzzy projects," previously weeks of senior-engineer dark matter, becomes a list of parallelizable, claimable, resumable sessions. Note it does not eliminate planning; it turns planning into agent-executable work itself. Matt's stated motivation: with AFK agents running batches overnight, the bottleneck was that the "planning stage really onerous" — planning was the last human cognitive step never sessionized.

Two: the map is the third "curated external memory" node, and a double-sided sample of interface-preserving structure. In the memory spectrum it is the third structure-preserving endpoint after CoE's experience trails and Synapse's association graphs — but the difference is "curation": the map is a co-designed human-machine memory, not passive accumulation. The positives: index-not-store + single source of truth + resolution layering, all hit. The negative also appears in field reports: in Discussion #484, muse83 (on their second project) reports pointer degradation — Claude gradually developed its own citation style ("#44 mentions... because #12 shows..."), becoming "almost incomprehensible" later on; the fix was adding an interface spec to CLAUDE.md (tickets referenced by topic rather than number, every number carrying its consequence). Pointers turning into jargon = the external memory's interface failing humans, patched manually to recover — structure preservation is not build-once; it is a protocol requiring continuous maintenance.

Three: the deepest insight is that "a constraint living in a file owned by the constrained is not a constraint." The most commonly reported failure mode: the agent writes production code mid-map-session. The official FAQ concedes the substance of the hole — the "plan, don't do" constraint is written in the map's Notes, but the Notes were written by the agent itself: users have watched an agent write "this map carries execution" into the Notes, then cite it as a license in later sessions and keep writing against a live server. A constraint written in a file owned by the constrained is not a constraint; it is a suggestion. This forms a neat duality with last week's Cordis piece: Cordis puts invariants into runtime mechanisms (inverse functions held by the runtime, LIFO guaranteed by structure), while Wayfinder puts invariants into the data layer (Notes text). The governance hierarchy for self-modifying systems: mechanism layer > external files > self-owned files. Wayfinder currently sits at the third tier — its biggest outstanding debt as a foundation for self-modifying systems.

Four: the tension between exploratory mechanism and the synthesis-planning instinct is real. Field report, verbatim: "I charted 27 tickets, and by the time I got to the thirteenth, the rest no longer made sense" — later tickets were built on assumptions already invalidated by earlier ones, precisely the waterfall trap it stands accused of. The mechanical antidote is fog (no pre-slicing) + invalidation handling; but the instinctive antidote is only one: define the destination narrowly enough (one map per deliverable, not per product). Community criteria have converged: "if the work fits in a single session, don't use Wayfinder" — heavier mechanisms always punish those who misjudge scale. Honesty about the evidence: the community splits three ways (heavy adopters / watchers still in grill-me mode / skeptics saying "it's just filing issues for yourself"), zero benchmarks. Observation point twelve already exists: whoever runs the controlled experiment comparing Wayfinder vs single-session planning owns the first hard dataset on planning workflows.

---

Sources: SKILL.md original text (mattpocock/skills, 240K stars, via GitHub API); Matt Pocock's original video 2026-07-30; aihero.dev official documentation (including FAQ and field reports); Latent Space interview 2026-08-20; GitHub Discussion #484; third-party summary at with-agents.dev. All figures verified against originals; one inflated paraphrase in Chinese video coverage has been flagged. Repost with attribution.

Tags

#wayfinder#ai-agents#planning#decision-tickets#matt-pocock#issue-tracking#fog-of-war#agent-workflows

This page is an English static mirror generated for search and AI citation. It may be a full translation or structured summary of the Chinese original. Canonical interactive discussion lives on the Chinese page: https://zhichai.net/topic/178634220