Wayfind (decision maps on a CreatorNotes canvas)

A loose idea has arrived: too big for one agent session, and wrapped in fog — the way from here to the destination is not visible yet. Wayfinding is about finding that way, not charging at the destination. This skill charts the way as a map canvas in CreatorNotes and works its tickets — Question notes whose resolution is a decision, not a slice of a build — one session at a time, until nothing is left to decide.

The pattern is borrowed from Matt Pocock's Wayfinder skill, re-homed from issue trackers onto CreatorNotes primitives. Everything here runs through the cnotes CLI; the cnotes skill documents every command used below (flags, output shapes, the operations contract, the humanizer) — consult it rather than guessing.

Plan, don't do

A map produces decisions. The pull to just do the work is usually the signal you have reached the edge of the map and it is time to hand off — say so. Task tickets (below) are the one sanctioned exception: they do real work only to unblock a decision, never to deliver the destination.

The model

The map is an index, not a store. Knowledge lives in note bodies; the canvas arranges it. cnotes canvas read <id> is the low-res load every session starts from — do not re-read every ticket body, zoom into the ones the chosen ticket touches.

Canvas anatomy

An orientation banner plus four section frames, created in chart mode and found by name thereafter:

• Tickets — every open Question. Blocking edges live here, so the frontier is visible at a glance: unblocked tickets have no inbound "blocks" edge from an open ticket.
• Decisions so far — resolved tickets beside their Decision notes. The index a session skims instead of re-reading history.
• Not yet specified — the fog ledger.
• Out of scope — work consciously ruled past the destination. Entries never graduate back; they return only if the destination itself is redrawn.

Fog or ticket?

The test is whether you can state the question precisely now — not whether you can answer it now.

• Ticket when the question is sharp, even if it is blocked and untakeable.
• Fog when you cannot phrase it that sharply yet. Do not pre-slice fog into ticket-sized pieces: a patch is coarser than a ticket and may graduate into several tickets, or none, once the frontier reaches it.

Ticket modes

Every ticket is HITL — human in the loop, worked with the human, who speaks for themselves — or AFK, driven by the agent alone. A HITL ticket only resolves through that live exchange; an agent that answers its own grilling questions has broken the loop. In a non-interactive session, take only AFK tickets.

• research (AFK) — a fact outside the workspace that a decision waits on: documentation, third-party APIs, the codebase, the market. Resolve via subagents. Research tickets are the one exception to one-per-session: several may run in parallel.
• prototype (HITL) — raise the fidelity of the discussion with a cheap concrete artifact to react to: an outline, a stub, rough UI. For UI flows the fat-marker-flows skill puts keyframes straight onto a canvas. Link the artifact from the Decision; heavy planning stays honest when there is something real to look at.
• grilling (HITL, the default) — a conversation, one question at a time (AskUserQuestion in Claude Code). Bring a lean per the Question rubric; the human decides.
• task (HITL or AFK) — manual work with nothing to decide that a decision is nevertheless blocked on: sign up for the service so its API can be judged, provision access, move the data so its shape can be seen. The agent drives it where it can; otherwise it hands the human a precise checklist. The Decision records what was done and the resulting facts (locations, URLs, counts) later tickets depend on.

Rules every session follows

1. One ticket per session, research excepted. Resolving a second burns the context the next ticket deserves.
2. Refer by name. In narration and note prose, tickets are their titles, never bare IDs. Mentions carry both: [QUESTION-12: Title](relationship:...).
3. Rubrics before writing. cnotes types show Question and cnotes types show Decision before authoring either; read the cnotes skill's humanizer reference before any prose.
4. Bracket in an operation. cnotes operations begin --prompt "<map name> · <ticket title>" before the first write, cnotes operations end after the last, every session, no exceptions.
5. Expect concurrency, know its limit. Claims stop two sessions taking the same ticket. But CreatorNotes allows one active operations run per user, so two of your sessions cannot both be writing: claim early, think freely, and hold the run only while recording. If begin refuses with a conflict, another session is mid-write — take a different ticket or wait.

Chart the map (first invocation)

The user arrives with a loose idea.

1. Settle the destination. Grill one question at a time until you can write the goal in one or two lines: what does reaching the end look like — a spec to hand off, a decision locked, a change made in place? The destination fixes scope, so it comes first.
2. Map the frontier, breadth-first. Fan out across the whole space rather than deep on any thread: what has to be decided, what is takeable now, what is dimly visible, what is already out of scope. If this surfaces no fog — the route is visible and fits one session — you do not need a map. Say so and offer to plan it right here.
3. Open the run, then create the map: cnotes canvas create "<Effort> · Wayfind Map" --goal "<destination>".
4. Mint the tickets you can phrase precisely, in one batch (cnotes notes create with @key cross-links for depends-on), plus one short fog note per dim patch. Read the Question rubric first; each ticket states the question, what it gates, and your lean where you have one. Tag wayfind plus the mode.
5. Place the map in one cnotes canvas place spec: orientation banner, the four sections with their contents, blocking edges (blocker → dependent, label "blocks"). Banner is at most five sentences, plain display IDs only — mention syntax corrupts richtext.
6. Fire the research subagents for frontier research tickets; fold whatever returns into resolutions (steps 4–6 of the work loop) before closing.
7. Close the run, surface the canvas link, stop. Charting resolves nothing else by hand.

Work the map (every later invocation)

The user names the map — or find it with cnotes canvas search "wayfind map" — and optionally a ticket.

1. Load the map: cnotes canvas read <id> --json, plus cnotes canvas digest <id> when returning after a gap. Orient to the goal before choosing anything.
2. Compute the frontier.
   • Open: Questions in the Tickets section with no outgoing answered-by (cnotes rel list --note QUESTION-N --json, batched over the section).
   • Unblocked: every depends-on target of the ticket is itself resolved.
   • Unclaimed: no open CLAIM comment on its node (cnotes canvas comments list <id> --status open) younger than about two hours. An older claim with no sign of life may be taken over — say so in your own claim text.
3. Choose and claim. The user's named ticket wins; otherwise take the first frontier ticket in reading order. Claim before any work: cnotes canvas comments add <id> --node QUESTION-N --text "CLAIM <ISO time> — resolving".
4. Resolve by mode. Zoom as needed: batch-fetch the bodies the ticket touches (cnotes notes get A B C), chase mentions, consult the skills the mode names. HITL means the human speaks for themselves; bring your lean and let them decide. If the ticket is itself a shaping question ("what shape should X take"), run the shaping skill inside this session.
5. Record the resolution, inside the run:
   • Create the Decision note to its rubric: what was decided, the alternatives weighed, the rationale, the revisit trigger. Link any artifacts (prototype canvas, research findings).
   • Save a new version of the ticket appending an ## Answered section: Answered by [DECISION-N: Title](relationship:answered-by). This mention IS the closed state the frontier computation reads.
   • Move the pair into Decisions so far: read the section's current members from the canvas, then one cnotes canvas arrange <id> --section SECTION-<n> call with those members plus the ticket and its Decision. Add an edge ticket → Decision labeled "answered by".
   • Resolve your claim comment (cnotes canvas comments resolve).
6. Advance the map.
   • Mint tickets the answer surfaced (create, then wire blocking).
   • Graduate fog the answer sharpened: mint the Question(s), then archive the fog note and remove it from the canvas — a graduated patch lives only as its tickets.
   • Rule out of scope anything the answer pushed past the destination: one-line Note in Out of scope mentioning the ruling Decision, archive the mis-scoped ticket, remove it from Tickets. A scope boundary is not a step on the route, so it stays out of Decisions so far.
   • Update or archive tickets the decision invalidated.
7. Close the run. Report the decision by name, what it unblocked, and the new frontier.

Finishing the map

The map is complete when the Tickets section and the fog ledger are both empty: nothing left to decide before someone goes and does the thing. Produce whatever the goal names as the destination — a spec note (or several) on the canvas, a plan, or the change itself. Every claim in that artifact mentions the Decision that settled it, so a reader or an agent confused by the summary can always reach the primary source. The artifact travels; the map stays as the record.