Build1 distinct publisher3 min readUpdated
The new skill exists because its author found the planning stage, not the execution stage, was the thing rationing how much work he could hand to agents overnight.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Matt Pocock has released a skill called /wayfinder, whose stated purpose is to help a developer and their agent work through a project where the end state is not entirely clear [4]. In the interview published by latent.space, he describes the thing it fixes as the planning stage, which he found onerous, rather than anything the agents did once dispatched [8].
That distinction is the whole story. Pocock says he was working with AFK agents, trying to schedule enough work that they could run virtually overnight, and that he already had a well-developed set of skills for turning work into a spec and then into tickets agents could crack on [6][7]. The part that broke was upstream: he was constantly having to think about session management, how many tokens he was into the context window, how deep he was going [8]. He described /wayfinder as a way to navigate "the fog of war," where you have a project but "you can't quite decide everything right at the start" [5].
The remedy he wanted was an orchestrator layer that takes over the planning sessions themselves, splitting work into multiple threads, doing prototyping and research, and pulling it back together [9]. The payoff he claims is second-order: more detailed specs, and therefore more work you can hand off to an AFK agent [10]. Note what that implies about where capacity is lost. Not in generation. In the human's tolerance for holding a large, half-decided plan in a finite context window.
The design detail worth stealing is the vocabulary. Pocock's kernel was not having to manage handoffs, plus a centralized document holding the pieces together [11]. He argues a skill is really context management for the agent you are in, so you have to work out the information flow first [12]. Asking what a managed child session needs produced two artefacts: a map, holding everything else and all the decisions already made, and the specific ticket that goes into the session [13][14]. He calls these precise terms "leading words," and says that if you call everything a ticket, or refer to the same thing differently in different places, the agent gets confused and you get strange behavior [15]. That is an unglamorous claim about naming discipline, and it is more testable than most claims made about agent frameworks.
Inside /wayfinder there are four named ticket types: grilling, prototype, research, and task, the last covering anything the human needs to do that the agent cannot [16][19]. Pocock says he has used it for a range of things, including planning courses [17]. The term "grilling session" runs through his account of the design, including the framing question of whether a grilling session could manage other grilling sessions, without being defined in the published interview [13].
What to watch: the interview carries no measurements. There is no figure for how many parallel planning sessions a run spawns, no token or cost accounting for the orchestration layer, and no before-and-after on how much overnight work a more detailed spec actually absorbs. The published text was condensed for readability, so the omissions may be editorial [18]. The audience numbers latent.space cites for Pocock, over 220,000 GitHub stars on his "AI Skills for Real Engineers" project and 347,000 YouTube subscribers, are the publisher's [2][3]; they say nothing about whether the map-and-ticket split holds up on a project you did not scope yourself. The cheap test is the naming claim: run one plan with consistent leading words and one without, and see if the child sessions drift.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Pocock said he wanted an orchestrator layer that would handle the planning sessions for him, splitting the work into multiple different threads, doing prototyping and research, and pulling it all back together.
Pocock said the result is that specs can be even more detailed, and you can dispatch an AFK agent to go and do tons more work.
Pocock said the design started from the kernel of not having to manage the handoffs, plus some kind of centralized document to hold all the pieces together.
Pocock said a skill is really about managing the context of the agent you are working in, so you need to think about the information flow.
Pocock framed the design question as what it would look like for a grilling session to manage other grilling sessions, and said the managed child session needs a vague overview of what else is happening plus its specific task. The interview does not define "grilling session."
Pocock said that yields two documents: a map, which is all of the rest of the stuff and all the decisions already made, and the specific ticket that goes into the actual session.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single first-party interview, no measurement
Everything rests on one article from one publisher, in which the skill's author is the sole source on problem, design and outcome. The design reasoning is coherent and internally consistent, which is why this is not near-zero, but there is no benchmark, no token or time measurement, no third-party trial, and the central vocabulary term 'grilling session' is left undefined. The reach metrics are asserted without a link.
Author-only usage at release
Observable adoption is a fresh release plus the author's own use across engineering, non-engineering and course planning. No third-party user, team, install count, download figure or downstream project appears anywhere in the cluster. The unverified GitHub star and subscriber figures describe the author's broader body of skills work and audience, not /wayfinder uptake.
Confident framing ahead of thin proof
The claim that planning rather than execution is the binding constraint on overnight agent work is presented as a discovered fact, and the preamble leads with very large reach numbers, yet the supporting material is one author's workflow anecdote with no measurement and no outside user. The design content is genuinely concrete, which keeps the gap moderate rather than severe, but the assertion outruns the evidence.
Promotional interview aligned with both parties' distribution
The publisher explicitly frames the piece as the launch of a recurring skills series intended to supply readers with new skills, and the interviewee is a skills author and course creator who says he uses /wayfinder to plan courses and has an unreleased AI coding dictionary. Both sides benefit from the skill and the format landing well; the article invites readers to go test /wayfinder. Nothing in the cluster is hidden, but no adversarial or independent voice is present.
Design detail trustworthy, effects and scale not
Confidence is reasonable that /wayfinder exists and is structured as described — the author is a direct, quoted primary source on his own artifact. It is low on whether the planning bottleneck generalises, whether the orchestrator layer actually produces better specs or more completed overnight work, and on the reported reach figures, all of which are single-sourced and unmeasured within a promotional format.
build
The reason your agent gets worse after an hour is that nothing ever leaves the context window1 distinct publisher
build
Invoked in three runs, executed in none: the cost rule that never got asked1 distinct publisher
build
Your inference bill is an architecture defect: declare the task before you call the model1 distinct publisher
build
Cursor's undocumented 'desktop' command turns local AI agents into a scriptable control channel1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 20, 2026