---
name: wayfind
description: Plan a big foggy chunk of work — more than one agent session can hold — as a decision map on a CreatorNotes canvas, then resolve it one Question per session until the way to the destination is clear. Use when the user invokes /wayfind, says "wayfind this" or "chart a map", asks to plan something too large or uncertain for one session, or points you at an existing wayfind map to continue ("work the map", "take the next ticket").
metadata:
  short-description: Chart and work multi-session decision maps on a canvas
---

# 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

| Concept | CreatorNotes shape |
|---|---|
| The map | One canvas, named `<Effort> · Wayfind Map` (interpunct `·`, never a dash) |
| Destination | The canvas **goal**: one or two lines on what reaching the end looks like — a spec handed off, a decision locked, a change made in place. Settled first; it fixes scope |
| Ticket | A **Question** note tagged `wayfind` plus one mode tag: `research`, `prototype`, `grilling`, or `task`. Sized to one agent session |
| Blocking | A `depends-on` mention in the dependent ticket's body pointing at its blocker, mirrored as a canvas edge labeled "blocks" from blocker to dependent |
| Resolved | The ticket carries an outgoing `answered-by` mention to a **Decision** note; the pair sits in the Decisions so far section |
| Frontier | Open tickets whose blockers are all resolved and which carry no live claim — computed fresh each session, never stored |
| Claim | An open canvas comment on the ticket node: `CLAIM <ISO time> — <what this session is doing>` |
| Fog | Short **Note**-type notes in the Not yet specified section: suspected questions too dim to phrase precisely yet |
| Out of scope | A one-line **Note** in the Out of scope section linking the Decision that ruled the work out |

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.