We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
🔥 TOP SIGNAL
Kent C. Dodds is operating a closed issue-to-merge loop. His Kody sequence is Sentry issue → root-cause analysis → Kody webhook → Cursor Cloud agent → Bugbot review → Kody merge and notification; the attached Discord notification reports a merged PR fixing PushRejectedError / base_moved and filtering an importScriptsNetworkError.
The reusable pattern is event-triggered work, an explicit review step, and a merge notification that leaves an audit trail—not another agent chat session.
⚡ TRY THIS
Use
/wayfinderfor the foggy parts. Install it withnpx skills@latest add mattpocock/skills --skill=wayfinder, then type/wayfinder. Matt Pocock’s rule is narrow: use it when the effort is larger than one agent session and you can name the destination but not the route; it creates decision tickets, plans rather than codes, and hands off when the map clears.Make the map a
wayfinder:mapissue with Destination, Decisions so far, Not yet specified, and Out of scope; let sessions claim frontier tickets, then run/to-spec #and/to-ticketsbefore implementation. Jumping directly from the map to code discards the linked decisions.Make browser agents optimize against traces. Sydney Runkle built a Map Tap agent with Browserbase Stagehand and LangChain DeepAgents: the first pass, given the docs, scored about 300/1000; she then asked her coding agent to inspect the trace and tune for speed with a smaller model and for accuracy with a higher score, returning 10 minutes later to inspect the result. Copy the loop—baseline, trace review, targeted change, rerun—and start from the Stagehand guide.
Review agent behavior in a live PR environment. Enable LangSmith Preview Builds in Deployment Settings → Preview Builds, choose Every PR or Label only, and set idle TTL and concurrency limits. Reviewers can run prompts, exercise tool calls, inspect traces, and hit failure paths; each new commit refreshes the preview. Use preview-scoped credentials because the deployment copies the parent’s secrets when created.
Put spend limits outside the agent. OpenAI says it deliberately does not stop users mid-task at a usage limit; Theo reports a long-running Codex goal consumed at least $800 in tokens after reaching 0% remaining. Add an external spend cap, wall-clock timeout, and kill switch before running persistent goals unattended.
📡 WHAT SHIPPED
Qwen3.8-27B is a serious local-fallback candidate. Agentic Coding Newsletter reports an Artificial Analysis Intelligence Index score of 52 and says the downloadable model runs on roughly 20–24GB of consumer-GPU VRAM. It runs through Ollama, LMStudio, or Unsloth Desktop, and the author recommends it as a local fallback in Hermes and other open-source harnesses; treat the score as a general-intelligence signal, not a coding benchmark.
Ox Alpha has high signal and very low verification. OpenCode’s announcement claims a free week, 1M-token context, multimodality, zero data retention, near-unlimited usage, and capacity for 100T tokens per day. Theo questioned the compute claim and said it was slaughtering internal benchmarks, while also finding it weak at design but surprisingly good at copy. His report of merging eight PRs without reading the code because Ox Alpha approved them is a trust experiment, not evidence that the stealth model is reliable.
LangSmith Preview Builds entered public beta. They create short-lived, production-like deployments from PR branches so teams can inspect traces, share feedback, and merge only after the agent behaves as expected.
Treg is an “OpenRouter for agent tools.” Its open-source catalog covers 2,630 endpoints across 47 providers, with pay-per-call provider pricing and no subscription or markup. In a hands-on test, the agent described the task, compared X-post API options, selected one, called it, and summarized the result; the pitch is “ask for the task, not the tool.” Try it at treg.to.
Bun 1.4 makes browser automation a small service. Simon Willison used Claude Code for web to build a zero-dependency, roughly 150-line TypeScript JSON API around
Bun.WebView, with/javascript,/screenshot, and/healthzendpoints and one browser tab per request. Bun can drive macOS WebKit or local Chromium over CDP; his test put a full Chrome service at roughly 192–256MB in a container.Framework migration is a concrete adoption pattern, not a demo. A current Pragmatic Engineer roundup reports that Asana used AI to rewrite a large Enzyme test suite in two weeks—work that otherwise would have been deferred—and says Airbnb and Uber have similar stories. Useful evidence for targeting repetitive, well-specified migrations first, but still a reported case study rather than an independent benchmark.
🎬 GO DEEPER
▶️ Kent C. Dodds — MCP explainer: Kent argues that MCP addressed a real problem and is good enough to evolve rather than be replaced.
Study Matt Pocock’s
skillsrepo: The interesting part is not the slash command but the information architecture—map as index, decision tickets as source of truth, and a frontier that controls what the next session sees. Read the failure notes too: the skill can drift into execution, over-plan a huge map, or create conflicting parallel grilling sessions.Study Simon Willison’s Bun.WebView JSON API: It is a compact example of using an agent to produce a useful browser primitive without a heavyweight automation stack, then measuring the real memory envelope before deployment.
Editorial take: The durable edge is shifting from “ask an agent to code” to a controllable system: map uncertainty, trigger bounded work, inspect behavior, and stop runaway spend.
Direct answer: The announcement supplies concrete setup, scope, and workflow details: trigger choices, auto-updating revisions, sharing/collaboration model, cleanup controls, secret handling, and beta availability/enablement.
Feature scope and runtime model: Preview Builds are a LangSmith Deployment feature that spins up a temporary, production-like deployment from a PR branch instead of requiring a new deployment per PR; the preview runs the code under review without updating the parent deployment .
Workflow and review capabilities: Reviewers can try prompts, exercise tool calls, inspect traces, test failure paths/edge cases; collaborators don't need to clone or reproduce the developer's local setup, and everyone reviews the same version in the same environment .
Sync with PR updates: LangSmith builds the latest commit from the PR source branch; each push to that branch automatically creates a new revision of the preview deployment, so the preview stays current through review without spinning up new environments or merging unfinished work .
Trigger configuration: Teams choose Every PR (preview for each pull request opened against the deployment branch) or Label only (preview after someone adds a configured GitHub label); Every PR suits teams where most changes need behavioral review, label only gives more control for selected changes .
Collaborator access model: Preview is a shared artifact tied to the pull request where product managers, domain experts, and QA can test the agent directly and leave feedback, while engineers inspect tool calls and traces behind responses; multiple previews can run at once and remain isolated per PR, allowing comparisons without moving a shared staging deployment .
Cleanup and usage controls: Idle TTL deletes a preview after its configured inactive period, max concurrent previews limits simultaneous previews per parent deployment, previews can be deleted manually at any time, and deleting the parent deployment deletes its previews .
Secrets behavior: Preview deployments copy the parent deployment's secrets when created and keep that initial set unless overridden; for sensitive services, use credentials scoped to preview workloads rather than production, especially if previews can be created from PRs by external or less-trusted contributors .
Setup/enablement: The feature is in Public Beta for deployments connected through the GitHub integration on LangSmith Cloud; enable via Deployment Settings → Preview Builds, choose Every PR or Label only, configure idle TTL and concurrency limit, then save; the next qualifying PR creates a preview from its source branch .
Gaps/uncertainty: Only this single announcement was supplied, so there is no separate launch post to compare against; the announcement also does not specify default or allowed values for idle TTL or concurrency limits, the exact GitHub label to configure, pricing or limits beyond beta availability, or any non-GitHub integration path.
/wayfinder skill extraction
Direct answer: The page fully specifies a replicable workflow: install via npx skills@latest add mattpocock/skills --skill=wayfinder, then type /wayfinder in the coding agent ; the agent will not reach for it on its own . Source repo is mattpocock/skills.
Installation & invocation
-
Install with
npx skills@latest add mattpocock/skills --skill=wayfinder; then type/wayfinder. - Invocation is manual; the agent won't reach for it on its own .
-
Trigger is narrow: effort genuinely larger than one agent session and the route foggy;
/grill-with-docsis the single-session alternative,/wayfinderis multi-session planning .
Workflow
- Takes an effort too big for one agent session and charts it as a shared map of decision tickets on the issue tracker, then resolves them one at a time until the way is clear .
- It plans, it does not do: every ticket holds a question whose resolution is a decision; the map is finished when nothing is left to decide; when clear, wayfinder hands off and does not carry on into code .
- Greenfield is not required; used on legacy and half-built codebases .
Map structure
-
The map is a single issue labelled
wayfinder:map; tickets are child issues; map is an index, not a store — a decision lives only in its ticket and the map gists and links . - Four things live on it: Destination, Decisions so far, Not yet specified (fog of war), Out of scope .
-
Frontier = open, unblocked, unclaimed tickets; a session claims a ticket by assigning it to itself before work; tickets are referred to by name, never bare
#42.
Ticket types
-
Every ticket carries a
wayfinder:label and is HITL or AFK . grilling(HITL, default): resolved by grilling plus domain-modeling in a fresh session .prototype(HITL): for "how should this look/behave", resolved by the prototype skill with the built artifact linked .research(AFK): for facts outside the working directory blocking a decision; resolved by a research subagent fired at charting time on aresearch/branch .task(either): manual work blocking a decision; done by the agent alone where it can, otherwise a precise checklist for the human .taskis the only type that does rather than decides, and earns its place by unblocking a decision, never by delivering a piece of the destination .- Research is the only exception to one ticket per session .
Configuration / prerequisites
-
Needs tracker wiring from
setup-matt-pocock-skills, which writes a "Wayfinding operations" section describing how map, child tickets, blocking edges, and frontier queries are expressed for GitHub, GitLab, or local markdown . -
Wayfinder resolves that doc through the pointer in
CLAUDE.md/AGENTS.md, not a fixed path; with no tracker configured it falls back to local markdown files . - Native blocking renders the frontier visually; a tracker without native dependency links (e.g., self-hosted Gitea) degrades to inferring blockers from the map text, which works but needs closer supervision .
- Any issue tracker works; GitHub is best-supported; GitLab, Linear, Jira and local markdown get used; local markdown puts artifacts in the repo, not recommended .
Operational rules
- Destination is the first act of charting, before any ticket exists, because it fixes the scope every ticket is measured against .
- Success criteria: destination written before tickets ; every open ticket reads as a question ; session resolves one ticket, posts answer, closes it, leaves one line on the map, then stops ; "Not yet specified" shrinks ; if opening grill finds no fog, skill stops and says the effort is small enough to skip the map ; finishing session hands toward a spec, not a PR .
-
A cleared map is not a build plan:
/to-speccollapses linked decisions into one spec (/to-spec #) and/to-ticketsslices into implementation tickets; looping straight into implement skips the collapse and throws linked detail away . - One-at-a-time is the safer default; parallel grilling duplicates questions because sessions share no context, and there is a known gap on prototype tickets where an agent may build three UI variations, choose one itself, and close the ticket — the selection is yours to make .
- If a closed decision turns out wrong, telling wayfinder plainly what changed makes it update the map, revise affected tickets, and comment on already-closed ones; no official guidance exists .
- Scope the map to a bounded destination rather than the whole product; maps scoped to one defined epic behave better; prototype aggressively — wayfinder is "prototypemaxxing", not "planmaxxing" .
Known gaps & conflicts
- The "plan, don't do" default can be overridden in the map's Notes, but Notes are agent-written, so the constraint and exemption live in the same file; one user watched an agent write "this map carries execution" into its own Notes and read it back as licence — no hard in-skill stop exists .
-
Grilling verbosity is the sharpest live complaint and is unresolved; mitigations in circulation: run lower reasoning effort and put a plain-language instruction in the global
CLAUDE.md. - A repeatedly-reported outcome: charting too many tickets and later ones no longer making sense; the default instinct is to plan comprehensively, which is the waterfall trap .
- Parallel prototype selection gap: skill does not currently say loudly enough that the choice of variation is the human's .
Versioning / composition
-
Renamed from
decision-mappingtowayfinderin v1.1; the skill kept "decision ticket" to stop people reading it as an implementation ticket . - Underneath it is mostly other skills wearing wayfinder's scheduling: grilling and domain-modeling resolve the default type, prototype resolves look/behavior, research runs as a subagent, handoff is the bridge in/out .
NVIDIA paid ~$6B for Poolside's AI "model factory", which swyx (Latent Space) says is "pumping out Thinky-beating models" — "actually not exaggeration, look at the numbers" — based on his podcast with Poolside's Eisokant . Reacting to the deal, Elie Bakouch says NVIDIA bought the model factory part of Poolside and many employees/researchers reportedly received offers from NVIDIA; he finds it unusual that founders remain at Poolside and speculates Poolside may become a neocloud/compute provider since no mention was made of PIC (Poolside infrastructure company) . Podcast episode: latent.space/p/poolside ; further ainews writeup: latent.space/p/ainews-poolside-gets-12b-reverse .
Matt Pocock (creator of "AI Skills for Real Engineers", 220k GitHub stars) released /wayfinder for planning projects where the end state is unclear — navigating "the fog of war." Use it when you "can't quite decide everything right at the start." Available at https://www.aihero.dev/skills-wayfinder
He built it because planning was the bottleneck: he runs AFK (away-from-keyboard) agents overnight from specs/tickets, but manual planning cost constant context-window and token management. /wayfinder acts as an orchestrator layer that splits planning across multiple threads (prototyping, research) and pulls everything back into detailed specs, so an AFK agent can "whack off tons more work."
Core architecture: a central map document holds all decisions made so far; each child session gets a specific ticket plus the map. Precise "leading words" — map, ticket, session — keep the agent from mixing up entities. Ticket types: grilling (Q&A alignment), prototype, research, and task (human-only work).
Decision rule: use his "grill me" skill when the whole plan fits in a single session and needs pre-alignment (most small features); use /wayfinder when you can't see the path ahead and need to explore.
He validated /wayfinder in Claude Code on a real project — rearchitecting his personal website (20+ years of content) — and also uses it for engineering, course planning, and other non-engineering work. He's building an unpublished "AI coding dictionary" (a graph of AI coding terms) so all his skills share a consistent vocabulary with agents: "a ubiquitous language between me and the agent."
swyx estimates the OpenClaw ecosystem drove $50–150M in Mac mini sales in 2026 — roughly +50% of normal annual worldwide Mac mini sales — replying to steipete's post about receiving 512GB RAM Mac Studios ("Apple was good to us") . This is swyx's rough estimate ("haha", "conservatively"), not official sales data.
Qwen3.8-27B, a 27B-parameter open-weight model, scores 52 on the Artificial Analysis Intelligence Index — within striking distance of frontier models while being downloadable and runnable on a consumer GPU with ~20–24GB VRAM at a decent clip . The author, who had for years concluded no local model could handle coding or long-horizon tasks, notes the 27B model is nearly as powerful as a 2.7-trillion-parameter Qwen model scoring 58 on the same index . It runs easily via Ollama, LMStudio, or Unsloth Desktop, and the author recommends it as the 'local fallback' model in their Hermes harness and other open-source agent harnesses .
Kent C. Dodds (@kentcdodds), a developer and educator, reports from firsthand use that he has had so much success with Grok 4.6 that he no longer bothers with other models anymore, and says he is looking forward to Grok 4.7 . In a follow-up to that post, he says it has been responsible for the last week or so of his work, linking to releases of his project Kody (https://github.com/kentcdodds/kody/releases) .
Chris McCormick (24-layer nanochat) now writes model code as a single compilable forward_backward function: no autograd (backward math written out like forward), no torch.nn modules, only matrices/math; each parameter gets a .gacc for gradient accumulation; intermediate activations are explicitly stashed for backward . In his activation stash, Claude "cleverly skipped a few" activations with high footprint and low compute cost; the MLP needs pre- and post-ReLU activations at 18GB each, so they store only pre and re-apply ReLU in backward . Chris notes he doesn't know the backward math — Claude wrote it all — and plans to gradually build the same familiarity as with the forward path . Karpathy: tearing down abstractions is increasingly appealing now that agents can handle the math, drudgery, and verification; most abstractions were built for a world with finite human intelligence and attention . Karpathy's extrapolation: the spec could be something like microgpt (scalar-valued Python with for loops), everything else is just compilation, and PyTorch etc. is "kind of a crappy IR" .
Matt Pocock's new /wayfinder skill — first in Latent Space's series on skills — is designed for the "fog of war": when you need to figure out a project but the end state isn't clear. It functions as a meta-skill that orchestrates research and other "grill" sessions to surface what you don't yet know . Per swyx, Pocock is now the top @aidotengineer speaker by total views and "arguably one of the best skills experts in the world"; his earlier /grill-me skill has reached "all echelons up to Satya Nadella (with some variations)" . The episode is an exclusive interview, tied to Richard MacManus's course launch this week as part of Latent Space's new Skills coverage . Details: https://www.latent.space/p/wayfinder-skill (linked from the post) ; thread: https://x.com/latentspacepod/status/2090546052847763862. This is secondhand promotion/announcement, not a firsthand workflow writeup.
Kent C. Dodds reports creating and merging 41 PRs in a single day, then 57 PRs done the next day — firsthand counts from his own workflow, with no specific tool named .
Kent C. Dodds (@kentcdodds) describes his production Sentry-triage agentic loop built on Kody (kodykoala) and Cursor Cloud agents: (1) a Sentry issue opens; (2) Sentry's root cause analysis runs; (4) Sentry calls a Kody webhook; (5) Kody spins up a Cursor Cloud agent to fix; (6) Bugbot reviews; (7) Kody merges and notifies him . A real Discord notification shows it shipping: "Sentry triage shipped: KODY-CLOUDFLARE-5M (+ siblings 5H/5G) • Fixed PushRejectedError on repo_publish_session → base_moved + session-branch force push • Filtered blob importScripts NetworkError (5G); 5H already fixed by #1570 • PR: https://github.com/kentcdodds/kody/pull/1603 (merged 0b4748da)" — so the loop goes issue → RCA → fix → review → merge without human interaction beyond a notification. He also announced an "Agentic Loops with Kent" session (https://luma.com/agentic-loops-with-kent) co-hosted with Kody, Sentry, and Cursor .
Simon Willison built a zero-dependency ~150-line TypeScript service (in his simonw/research repo) that replicates his shot-scraper javascript CLI as a JSON API using Bun 1.4's new experimental Bun.WebView, without Puppeteer or Playwright. It creates one browser tab per request for concurrency and exposes /javascript, /screenshot, and /healthz endpoints returning page results and errors as JSON. He used "Claude Code for web" to build the prototype, and measured that the service needs a 192MB-256MB container to run a full Chrome against complex web pages (tested via cgroups) . Bun 1.4 released as the first stable version since its Zig-to-Rust rewrite, adding features including Bun.WebView (browser automation via macOS WebKit or local Chromium over CDP), Bun.Image, Bun.cron(), bun run --parallel, and claims 1,517 new Node.js test suite passes, 2,900+ bug fixes, 5x lower idle CPU, up to 35% lower memory, and 50% faster Linux startup — though the rewrite itself was downplayed in the release notes .
Dev educator Kent C. Dodds (@kentcdodds) posted a video aimed at "MCP haters," arguing that the problem MCP solves was worth solving and that MCP's solution is good enough to evolve rather than get replaced, with his explanation in the video . He posted the video to his YouTube channel: https://www.youtube.com/watch?v=1B9H6RTAGmE&list=PLV5CVI1eNcJhP4nrJt85L7PxHjebFpDfY
@letstri, defending T3 Code, says it is "free" and "open-source", has customers even though users are not paying anything yet, and requires signing up via Clerk before use . He also notes open-source means the code is viewable, not that maintainers must accept pull requests .
Anthropic plans to change its data retention policy for advanced 'Mythos-class' AI models: enterprise customers can own and control their own data, with Anthropic retaining none; the change is coming this fall . Boris Cherny of Anthropic says they've been working on this with customers because enterprises need to meet their own privacy and compliance rules — firsthand confirmation of the policy . The tweet responds to a Bloomberg report on the planned policy change .
Official @LangChain roadshow 'Building Agents with Agents' hits Sunnyvale on Thu Aug 27 (RSVP: https://events.langchain.com/LangSmithRoadshow/SiliconValley/) with a keynote on trending agent architectures, Expedia's ML director on agent building, and hands-on workshops on agent harnesses (Deep Agents) and improving agents with LangSmith Engine .
Hands-on review of treg (treg.to), an open-source "OpenRouter for agent tools" for the API-discovery pain point in agent workflows . Workflow: describe the job, treg searches its catalog and shows available providers and prices, then the agent calls the selected endpoint with one token . Tested with the real task "What AI coding topics are trending on X right now?": the agent searched for an X post API, compared options, picked one, pulled the posts, and summarized the topics . Tagline: "Ask for the task, not the tool" . Catalog: 2,630 endpoints across 47 providers; pay per call at provider rates, no subscription or markup; open source . Jason Zhou (@jasonzhou1993) pitched it as giving CodeX access to 2600+ APIs for free at treg.to .
- The @opencode account announced Ox Alpha, a stealth model free for the next week: 1M token context, multi-modal, zero data retention, generous/near-unlimited rate limits, and claimed capacity for 100T tokens per day (announcement).
- Theo (@theo) questioned the compute claim ("Okay who the fuck made this model and where did they get this much compute?") but reports from firsthand testing that it is "slaughtering all our internal benchmarks" , while being "not good at design but ... surprisingly good at copy" .
In a post Theo replied to, @teortaxesTex reports Ox Alpha is a frontier model — more well-done than any other Chinese model, better than Kimi K3, and fast — and half-suspects it's a stolen Claude checkpoint . Theo reacted with "wtf is this model? Seriously" , signaling interest.
Sydney Runkle (@sydneyrunkle) built a browser agent combining Browserbase's stagehand and LangChain's deepagents to play "Map Tap" — an agentic web-navigation task where she must drag a map, zoom, and click close to an assigned global city . One-shotting the agent with just Browserbase + LangChain docs scored ~300/1000 points; she then had her coding agent review the trace and optimize for speed (smaller model) and accuracy (higher score), returning 10 minutes later to see the improved result . Workflow guide: https://docs.langchain.com/oss/python/integrations/tools/stagehand. LangChain highlights that such browser agents can click, scroll, screenshot, and extract structured data .
The /wayfinder Skill
08 / 25AI Skills for Real Engineers · 12 min read
Chart a large effort as a map of decisions, and settle them.
Matt Pocock
Install this skill
npx skills@latest add mattpocock/skills --skill=wayfinder
Then type /wayfinder in your coding agent.
Source
What it does
wayfinder takes an effort too big for one agent session (opens in new tab): an idea whose destination you can name but whose route you cannot yet see, and charts it as a shared map of decision tickets on your issue tracker, then resolves them one at a time until the way is clear.
It plans, it does not do. Every ticket holds a question whose resolution is a decision, not a slice of a build to execute, and the map is finished when nothing is left to decide before someone goes and builds the thing. That one rule is what separates a wayfinder ticket from an ordinary implementation ticket (opens in new tab), and it is the rule agents break most often. When the map clears, wayfinder hands off; it does not carry on into code.
When to reach for it
You invoke this by typing /wayfinder; the agent (opens in new tab) won’t reach for it on its own.
It is the heaviest, densest flow in the set, so the trigger is narrow: the effort has to be genuinely larger than one agent session can hold, and the route to the destination has to be foggy. The split is a clean one: /grill-with-docs for single-session planning, /wayfinder for multi-session planning.
| What you have in front of you | What to run |
|---|---|
| A well-scoped feature you can settle in one sitting | grill-me (opens in new tab), or grill-with-docs (opens in new tab) when there is a codebase |
| A greenfield project, or a build spanning many sessions, with the route still unclear | /wayfinder |
| A thread where the deciding is already done | to-spec (opens in new tab): skip straight past the map |
| A cleared wayfinder map | to-spec (opens in new tab), then to-tickets (opens in new tab) and implement (opens in new tab) |
| An existing session that has already grown too big |
say “hand off to /wayfinder “ (handoff (opens in new tab) bridges into a map as well as out of one) |
Greenfield is not a requirement. Wayfinder is used routinely on legacy and half-built codebases, and it is arguably sharper there, because a lot of the fog is “what is already true here” rather than “what should we do”.
Prerequisites
The map and its tickets live on the repo’s issue tracker, so wayfinder needs the tracker wiring that setup-matt-pocock-skills (opens in new tab) lays down. That step writes a “Wayfinding operations” section describing how the map, its child tickets, blocking edges, and frontier queries are expressed for GitHub, GitLab, or local markdown. Wayfinder resolves that doc through the pointer in your CLAUDE.md / AGENTS.md rather than a fixed path; with no tracker configured at all it falls back to local markdown files.
The tracker is not decoration. Blocking is what renders the frontier visually in the tracker’s own UI, and a tracker without native dependency links (a self-hosted Gitea, say) degrades wayfinder to inferring blockers from the map text, which works but needs closer supervision.
The map, the fog, and the frontier
The map is a single issue labelled wayfinder:map; its tickets are its child issues. It is an index, not a store: a decision lives in exactly one place, its ticket, and the map only gists it and links. A session loads the map at low resolution and zooms into individual tickets on demand, which is what lets a map keep growing without every session paying for its whole history.
Four things live on it:
- Destination: what reaching the end of this map looks like. Naming it is the first act of charting, before any ticket exists, because the destination fixes the scope every ticket is measured against.
- Decisions so far: one line per closed ticket, each linking to where the detail actually lives.
- Not yet specified: the fog of war. Decisions you can tell are coming but cannot yet phrase sharply. The test for fog versus ticket is whether you can state the question precisely now, not whether you can answer it. Resolving a ticket clears the fog ahead of it and graduates whatever is now specifiable into fresh tickets.
- Out of scope: work ruled beyond the destination. Fog only ever gathers toward the destination, so out-of-scope work is closed and never graduates.
The frontier is the open, unblocked, unclaimed tickets (the edge of the known). A session claims a ticket by assigning it to itself before doing any work, so the assignee is the claim and concurrent sessions skip it. Tickets are referred to by name throughout, never by a bare #42; a wall of issue numbers is illegible in narration.
The four decision-ticket types
Every ticket carries a wayfinder:<type> label, and is either HITL (opens in new tab) (worked with a human who speaks for themselves) or AFK (opens in new tab), driven by the agent alone. A HITL (opens in new tab) ticket only resolves through the live exchange; an agent that answers its own grilling (opens in new tab) questions has broken it.
| Type | Mode | Reach for it when | Resolved by |
|---|---|---|---|
grilling | HITL | The default. The question can be settled by talking it through. | grilling (opens in new tab) plus domain-modeling (opens in new tab), in a fresh session |
prototype | HITL | “How should this look” or “how should this behave”: a question talking cannot settle. | prototype (opens in new tab), with the built artifact linked from the ticket as an asset |
research | AFK | A fact outside the working directory is blocking a decision. |
A research (opens in new tab) subagent (opens in new tab), fired at charting time and burned down in parallel on a research/<name> branch |
task | Either | Nothing to decide, but manual work blocks a decision, such as provisioning access, signing up for a service, or moving data so its shape can be seen. | The agent alone where it can, otherwise a precise checklist for the human |
task is the only type that does rather than decides, and it earns its place by unblocking a decision, never by delivering a piece of the destination. This is the type that goes wrong most often in practice: agents interpret it as an implementation step and start writing product code inside the map.
Research is the only exception to one ticket per session.
Common questions
How is this different from /grill-with-docs? Which should I start with? Session count, not project size. /grill-with-docs is single-session planning; wayfinder is multi-session planning. If you can hold the whole thing in one conversation, grilling (opens in new tab) is the cheaper and better tool, and wayfinder is genuinely slower and denser for that case. The community shorthand that has settled on it: wayfinder only makes sense if the work doesn’t fit into a single session. This is by a distance the most-asked wayfinder question, and it keeps being asked because the descriptions do not tell you where your own task sits on that line. You have to judge the session count yourself.
When it asks for the “destination”, does it mean the end of this session or the end of everything? The whole map. That means the destination of the entire map, not just the initial session. The question reads ambiguously because wayfinder is by definition a multi-session tool, so a session-scoped answer never makes sense. Typical destinations are a spec (opens in new tab) to hand off, a decision to lock before planning starts, a proof of concept, or a change made in place like a data migration.
The map is cleared. Didn’t wayfinder already write the spec and make the tickets? Why do I still need /to-spec and /to-tickets? No. Wayfinder’s tickets are decision tickets, and by the time the map closes they are all closed too. What is left is a map full of linked decisions, which is not a build plan. to-spec (opens in new tab) collapses those linked decisions into one spec (/to-spec #<map_issue>) and to-tickets (opens in new tab) slices that into tracer-bullet implementation tickets. Looping the map straight into implement (opens in new tab) skips the collapse and throws the linked detail away. Go straight to implementation only when the effort turned out genuinely small. People do run the abbreviated pipeline and report it working; the two extra steps buy you an explicit spec artifact that a reviewer or a colleague can read, which matters more the less solo you are.
My agent started writing production code in the middle of a wayfinder session. The most-reported failure with this skill, and there is a real hole behind it. Wayfinder’s “plan, don’t do” default can be overridden in the map’s Notes, but the Notes are written by the agent, so the constraint and its exemption live in the same file the constrained party owns. One user watched an agent write “this map carries execution” into its own Notes and then read it back in later sessions as its own licence, building on a live server. There is no hard in-skill stop for “I meant the default.” Until there is: read the Notes on any map you didn’t chart yourself, keep implementation in its own sessions, and treat any wayfinder:task that looks like a slice of the build as mis-typed.
I charted 27 tickets, and by the time I got to the thirteenth, the rest no longer made sense. A real and repeatedly-reported outcome, verbatim from a field report. Wayfinder’s default instinct is to plan comprehensively, and a map whose later tickets rest on assumptions the earlier ones invalidate is exactly the waterfall trap the skill is accused of. Two things push back on it. Scope the map to a bounded destination rather than to the whole product. Practitioners consistently report that maps scoped to one defined epic behave better than a sprawling “implement V1”, and planning something very big is not the goal in the first place: shipping small increments is. And prototype (opens in new tab) aggressively: the whole reason the route stays current is that uncertainty is flushed out by cheap concrete artifacts before implementation depends on it. Wayfinder is “prototypemaxxing”, not “planmaxxing”.
Can I work several tickets in parallel? The frontier is built to show you what is takeable, and blocking edges are there so parallel work is safe on paper. In practice one-at-a-time is the safer default. Users working two grilling tickets at once get asked in one session a question they just answered in the other, because the sessions share no context (opens in new tab). There is also a known gap on prototype tickets: an agent has been reported building three UI variations, choosing one itself, and closing the ticket. The selection is yours to make, and the skill does not currently say so loudly enough. If you do run in parallel, review the dependency graph yourself first.
Do I have to use GitHub Issues? No. Any issue tracker works. GitHub is the best-supported path because its native sub-issues and blocking relationships are what make the frontier visible without opening the map; GitLab, Linear, Jira and local markdown all get used. Two honest caveats. A tracker with no native blocking means the dependency graph is inferred from text and needs manual correction. And local markdown puts the artifacts in your repo, which is not recommended: storing this material in the repo tends to lead to accidental persistence. Open-source maintainers hit the opposite problem (public trackers filling with agent-generated planning tickets) and tend to choose local markdown anyway.
The grilling is exhausting. Every question is three paragraphs long. This is the sharpest live complaint about wayfinder and it is not resolved. The decomposition one user gave: the verbosity itself causes decision exhaustion, and the length strips out why a question is being asked, so you lose the chain from decision to decision as the map gets longer. The verbosity looks like a property of the current set of models (opens in new tab) rather than of the skill, and no fix has landed. Practitioner mitigations in circulation: run a lower reasoning effort (opens in new tab), and put a plain-language instruction in your global CLAUDE.md. Expect to spend real thought here regardless, since the amount of thinking wayfinder demands from you is not a defect but most of what it is for.
A decision I already closed turned out to be wrong. Do I edit the old ticket or make a new one? There is no official guidance, and the agent’s instinct is unhelpful: it tends to design around the bad decision rather than challenge it, so you have to steer manually. What does work is telling wayfinder plainly what changed; it updates the map, revises the affected tickets, and comments on already-closed ones. Scope changes mid-map are recoverable. A map you designed to change is a scoping smell.
Where did decision-mapping go? It is this skill, renamed to wayfinder in v1.1 and invoked as /wayfinder. “Decision map” was jargon and was also inaccurate, since only one of the four ticket types is really a decision by itself. The reframe gave the skill one coherent vocabulary (destination, fog of war, frontier, the map) instead of an invented term layered on top. The unit kept the “decision” word, though: a decision ticket is what a wayfinder ticket is called, precisely to stop people reading it as an implementation ticket.
It’s working if
- The destination is written down and agreed before a single ticket exists.
- Every open ticket reads as a question. Any ticket that reads “build the X” is either mis-typed or belongs downstream of the map.
- You can look at your tracker and see which tickets are takeable without opening the map, since that is the frontier rendering itself through native blocking.
- A session resolves one ticket, posts the answer as a resolution comment, closes it, and leaves one line on the map’s Decisions so far. Then it stops.
- Not yet specified shrinks over time. A patch of fog that graduates into a ticket disappears from that section rather than living in both places.
- When the opening breadth-first grill turns up no fog at all, the skill stops and tells you the effort is small enough to skip the map.
- The session that finishes the map hands you toward a spec, not a pull request.
Where it fits
wayfinder is a situational on-ramp, not the default front door. The grill-led idea → ship chain is still where most work starts; wayfinder is what you climb onto when the idea is too big to hold in one session, and it merges back onto that chain at to-spec (opens in new tab), because a cleared map hands off rather than builds.
Underneath, it is mostly other skills wearing wayfinder’s scheduling: grilling (opens in new tab) and domain-modeling (opens in new tab) resolve the default ticket type, prototype (opens in new tab) resolves the tickets that talking cannot, and research (opens in new tab) runs as a subagent (opens in new tab) so its reading never lands in your session. handoff (opens in new tab) is the bridge in and out: into a map from a conversation that outgrew itself, out of one when a side quest appears mid-session. For anything else, ask-matt (opens in new tab) routes over the whole set.
/wayfinder skill extraction
Direct answer: The page fully specifies a replicable workflow: install via npx skills@latest add mattpocock/skills --skill=wayfinder, then type /wayfinder in the coding agent ; the agent will not reach for it on its own . Source repo is mattpocock/skills.
Installation & invocation
-
Install with
npx skills@latest add mattpocock/skills --skill=wayfinder; then type/wayfinder. - Invocation is manual; the agent won't reach for it on its own .
-
Trigger is narrow: effort genuinely larger than one agent session and the route foggy;
/grill-with-docsis the single-session alternative,/wayfinderis multi-session planning .
Workflow
- Takes an effort too big for one agent session and charts it as a shared map of decision tickets on the issue tracker, then resolves them one at a time until the way is clear .
- It plans, it does not do: every ticket holds a question whose resolution is a decision; the map is finished when nothing is left to decide; when clear, wayfinder hands off and does not carry on into code .
- Greenfield is not required; used on legacy and half-built codebases .
Map structure
-
The map is a single issue labelled
wayfinder:map; tickets are child issues; map is an index, not a store — a decision lives only in its ticket and the map gists and links . - Four things live on it: Destination, Decisions so far, Not yet specified (fog of war), Out of scope .
-
Frontier = open, unblocked, unclaimed tickets; a session claims a ticket by assigning it to itself before work; tickets are referred to by name, never bare
#42.
Ticket types
-
Every ticket carries a
wayfinder:label and is HITL or AFK . grilling(HITL, default): resolved by grilling plus domain-modeling in a fresh session .prototype(HITL): for "how should this look/behave", resolved by the prototype skill with the built artifact linked .research(AFK): for facts outside the working directory blocking a decision; resolved by a research subagent fired at charting time on aresearch/branch .task(either): manual work blocking a decision; done by the agent alone where it can, otherwise a precise checklist for the human .taskis the only type that does rather than decides, and earns its place by unblocking a decision, never by delivering a piece of the destination .- Research is the only exception to one ticket per session .
Configuration / prerequisites
-
Needs tracker wiring from
setup-matt-pocock-skills, which writes a "Wayfinding operations" section describing how map, child tickets, blocking edges, and frontier queries are expressed for GitHub, GitLab, or local markdown . -
Wayfinder resolves that doc through the pointer in
CLAUDE.md/AGENTS.md, not a fixed path; with no tracker configured it falls back to local markdown files . - Native blocking renders the frontier visually; a tracker without native dependency links (e.g., self-hosted Gitea) degrades to inferring blockers from the map text, which works but needs closer supervision .
- Any issue tracker works; GitHub is best-supported; GitLab, Linear, Jira and local markdown get used; local markdown puts artifacts in the repo, not recommended .
Operational rules
- Destination is the first act of charting, before any ticket exists, because it fixes the scope every ticket is measured against .
- Success criteria: destination written before tickets ; every open ticket reads as a question ; session resolves one ticket, posts answer, closes it, leaves one line on the map, then stops ; "Not yet specified" shrinks ; if opening grill finds no fog, skill stops and says the effort is small enough to skip the map ; finishing session hands toward a spec, not a PR .
-
A cleared map is not a build plan:
/to-speccollapses linked decisions into one spec (/to-spec #) and/to-ticketsslices into implementation tickets; looping straight into implement skips the collapse and throws linked detail away . - One-at-a-time is the safer default; parallel grilling duplicates questions because sessions share no context, and there is a known gap on prototype tickets where an agent may build three UI variations, choose one itself, and close the ticket — the selection is yours to make .
- If a closed decision turns out wrong, telling wayfinder plainly what changed makes it update the map, revise affected tickets, and comment on already-closed ones; no official guidance exists .
- Scope the map to a bounded destination rather than the whole product; maps scoped to one defined epic behave better; prototype aggressively — wayfinder is "prototypemaxxing", not "planmaxxing" .
Known gaps & conflicts
- The "plan, don't do" default can be overridden in the map's Notes, but Notes are agent-written, so the constraint and exemption live in the same file; one user watched an agent write "this map carries execution" into its own Notes and read it back as licence — no hard in-skill stop exists .
-
Grilling verbosity is the sharpest live complaint and is unresolved; mitigations in circulation: run lower reasoning effort and put a plain-language instruction in the global
CLAUDE.md. - A repeatedly-reported outcome: charting too many tickets and later ones no longer making sense; the default instinct is to plan comprehensively, which is the waterfall trap .
- Parallel prototype selection gap: skill does not currently say loudly enough that the choice of variation is the human's .
Versioning / composition
-
Renamed from
decision-mappingtowayfinderin v1.1; the skill kept "decision ticket" to stop people reading it as an implementation ticket . - Underneath it is mostly other skills wearing wayfinder's scheduling: grilling and domain-modeling resolve the default type, prototype resolves look/behavior, research runs as a subagent, handoff is the bridge in/out .