Core Thesis
"Nothing is too big to plan anymore" — the precise claim is sharper than the headline version: when the volume of unresolved decisions in a piece of work exceeds what one agent session can reliably hold, a coordination mechanism is needed. The binding constraint is not project size, but total uncertainty ÷ session window.
Author context: Matt Pocock, a leading TypeScript educator (aihero.dev, 347k YouTube subscribers), whose mattpocock/skills repo reached 240k stars (verified via GitHub API; 220k at the time of Latent Space's Aug 20 coverage). Wayfinder shipped with v1.1 (July 2026), which also upgraded to-prd/to-issues into to-spec/to-tickets.
The Core Reframe: Decision Tickets, Not Task Slices
The SKILL.md definition is precise: decision tickets are "questions whose resolution is a decision, not slices of a build to execute." This is the dividing line from all traditional planning methods:
| | Traditional WBS / todo | spec-first (PRD) | single-session grilling | wayfinder | |---|---|---|---|---| | Object of planning | task slices | full spec | decisions discussable on the spot | all unresolved decisions | | Attitude to unknowns | pretends omniscience, slices anyway | risk register (sidecar) | unspeakable issues leak through | fog is a first-class citizen | | Carrier | documents | documents | session history | a map on the issue tracker | | Sessions | — (humans read docs) | 1 | 1 | N, concurrent | | Output | task list | spec | decision record | decision map → collapses into spec via to-spec |
Four ticket types correspond to four cognitive actions:
- research (AFK — sub-agents fired out in parallel, for facts outside the working directory)
- prototype (HITL — when look/feel can't be settled by conversation, build a cheap rough artifact to react to)
- grilling (HITL, the default — conversation-solvable; "the agent answering its own probing questions = broken ticket")
- task (the only type that *does* rather than *decides*; must exist in the name of unlocking some decision)
Fog of War: Mechanizing "Knowing What You Don't Know"
Fog of war (Warcraft III style) is not rhetoric; it's an operational criterion. The fog-vs-ticket test has exactly one clause: can you state the question precisely right now (not answer it). Can state it → open a ticket. Cannot → leave it in fog, and pre-slicing fog into ticket-sized chunks is forbidden — because resolving one ticket illuminates the terrain ahead, letting fog "graduate" into new tickets; pre-cut blocks are guesses of terrain made before illumination.
Side effects of resolving a ticket: fog graduates, out-of-bounds territory gets judged out of scope, and other tickets may become invalid. Fog only converges toward the destination — this is the orthogonality of scope and sharpness: things out of scope can be perfectly clear, but clarity is not on the 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, anchoring the scope ruler of every ticket) / Decisions so far / Not yet specified (fog) / Out of scope.
Multi-session coordination reuses the classics of distributed systems, all riding on native issue-tracker features: assignee-as-lock (claim before working; concurrent sessions skip claimed tickets), native blocking edges (dependency graph visualized directly in the tracker UI), and frontier (open + unblocked + unclaimed = the actionable edge). The honest unit of ticket sizing: one per 100K-token session.
Editorial Observations
One: it fills in the "planning-side" node on the task-definition-cost-collapse axis. The mainline axis (teleoperation → simulation → bootstrapping → deployment collapse) describes four levels of execution-side cost reduction; wayfinder compresses the definition side — defining a "large vague project," once weeks of senior-engineer dark matter, becomes a parallelizable, claimable, resumable list of sessions. Note it does not abolish planning; it turns planning into agent-executable work itself. Matt's stated motivation: with AFK agents running overnight batches, the bottleneck is that the "planning stage [is] really onerous" — planning is the last human cognitive stage not yet sessionized.
Two: the map is a third "curated external memory" node — and a double-sided sample of structure-preserving interfaces. In the memory spectrum it is the third structure-preserving endpoint after CoE's experience trails and Synapse's association graphs — with the distinction of being *curated*: the map is co-designed human-machine external storage, not passive accumulation. Positives: index-not-store, single source of truth, resolution layering — all hits. The negative shows up in field reports: Discussion #484's muse83 (second project) reports pointer degradation — Claude gradually developed its own citation style ("#44 mentions... because #12 shows..."), becoming "almost unreadable" late in the project; the fix was adding an interface spec to CLAUDE.md (refer to tickets by topic, not number; every number carries its consequence). When pointers turn into jargon, the external-memory interface fails for humans, and manual patching restores it — structure preservation is not build-once; it's a continuously maintained protocol.
Three: the deepest insight — "constraints living in files owned by the constrained are not constraints." The most-reported failure mode: the agent writing 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 are written by the agent itself: one user watched the agent write "this map carries execution" into the Notes, then cite it as a license in later sessions and keep writing on 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); wayfinder puts them in the data layer (Notes text). Governance tiers for self-modifying systems: mechanism layer > external files > self-owned files. Wayfinder currently sits at tier three — its largest outstanding debt as a foundation for self-improving systems.
Four: the tension between exploratory mechanism and the planning instinct is real. From the field reports: "I charted 27 tickets, and by the time I got to the thirteenth, the rest no longer made sense" — later tickets built on assumptions invalidated by earlier ones, precisely the waterfall trap it stands accused of. The mechanistic antidote is fog (no pre-slicing) plus invalidation handling, but the instinctive antidote is one thing only: define the destination narrowly enough (one map per deliverable, not per product). Community judgment has converged: "if the work fits in a single session, don't use wayfinder" — heavier mechanisms always punish those who misjudge scale. Honesty about evidence: the community splits three ways (heavy adopters / grilling-stage wait-and-seers / "it's just filing issues to yourself" skeptics), with zero benchmarks. A twelfth observation point has appeared: whoever runs the controlled experiment of "wayfinder vs single-session planning" gets the first hard data on planning workflows.
---
Sources: SKILL.md original text (mattpocock/skills, 240k stars, GitHub API); Matt Pocock's original video, 2026-07-30; aihero.dev official docs (incl. FAQ and field reports); Latent Space interview, 2026-08-20; GitHub Discussion #484; with-agents.dev third-party summary. All figures checked against sources.