From mattpocock-skills
Charts a path through ambiguous problems by creating investigation tickets on the issue tracker, then resolving them incrementally to clarify the route.
How this skill is triggered — by the user, by Claude, or both
Slash command
/mattpocock-skills:wayfinderThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A loose idea has arrived — too big for one agent session, and wrapped in fog: the route from here to a plan isn't visible yet. This skill charts it as a **shared map** on the repo's issue tracker, then works its tickets one at a time. The map is domain-agnostic — engineering work, course content, whatever fits the shape.
A loose idea has arrived — too big for one agent session, and wrapped in fog: the route from here to a plan isn't visible yet. This skill charts it as a shared map on the repo's issue tracker, then works its tickets one at a time. The map is domain-agnostic — engineering work, course content, whatever fits the shape.
The map is a single issue on this repo's issue tracker, labelled wayfinder:map — the canonical artifact. Its tickets are child issues of the map.
The map is an index, not a store. It lists the decisions made and points at the tickets that hold their detail; a decision lives in exactly one place — its ticket — so the map never restates it, only gists it and links.
Where the map, its child tickets, blocking, and frontier queries physically live is tracker-specific. Consult docs/agents/issue-tracker.md (the "Wayfinding operations" section) for how this repo expresses them. If that doc is absent, default to the local-markdown tracker.
The whole map at low resolution, loaded once per session. Open tickets are not listed — they are open child issues, found by query.
## Notes
<domain; skills every session should consult; standing preferences for this effort>
## Decisions so far
<!-- the index — one line per closed ticket: enough to judge relevance, then zoom the link for the detail the ticket holds -->
- [<closed ticket title>](link) — <one-line gist of the answer>
## Fog
<!-- see "Fog of war" for what belongs here -->
Each ticket is a child issue of the map; the tracker's issue id is its identity. Its body is the question, sized to one 100K token agent session:
## Question
<the decision or investigation this ticket resolves>
Two label families:
wayfinder:<type> — one of research, prototype, grilling, task (see Ticket Types).wayfinder:claimed — a session sets this first, before any work, so concurrent sessions skip it.Blocking uses the tracker's native semantics. A ticket is unblocked when every ticket blocking it is closed. The frontier is the open, unblocked, unclaimed children — the edge of the known.
The answer isn't part of the body — it's recorded on resolution (see Work through the map). Assets created while resolving a ticket are linked from the issue, not pasted in.
The map is deliberately incomplete: don't chart what you can't yet see. Beyond the tickets lies fog — the dim view of decisions and investigations you can tell are coming but can't yet pin down, because they hang on questions still open. Resolving a ticket clears the fog ahead of it, graduating whatever's now specifiable into fresh tickets — one at a time, until the way to the goal is clear and no tickets remain.
The map's Fog section is where that dim view is written down: the suspected question, the area to revisit later, the risk you're deferring. Write as loosely or as fully as the view allows; it doubles as a signpost for collaborators reading where the effort is headed.
Fog or ticket? The test is whether you can state the question precisely now — not whether you can answer it now.
Fog excludes only what's already decided (that's Decisions so far) and what's already a ticket.
Two modes. Either way, every session ends with a Handoff — never resolve more than one ticket per session.
User invokes with a loose idea.
/grilling and /domain-modeling session to surface the open decisions.wayfinder:map): Notes filled in, Decisions-so-far empty, Fog sketched.User invokes with a map (URL or number). A ticket is optional — without one, you pick the next decision, not the user.
wayfinder:claimed and save before any work.## Notes block names. If in doubt, use /grilling and /domain-modeling.The user may run unblocked tickets in parallel, so expect other sessions to be editing the tracker concurrently.
End every session with a Next steps block the user can copy-paste. Two cases:
Open tickets remain. Query the map for the currently-unblocked children, then give two copy-paste options: a bare command for one session (you pick the next ticket), and one pinned command per unblocked ticket for running them in parallel. Paste one line per fresh window — opening one, some, or all of them.
Next steps — 3 tickets unblocked. Clear the context, then open fresh sessions.
One session — resolves the next unblocked ticket:
Invoke /wayfinder with the map <map-url>.Parallel — paste one line per window, up to all 3:
Invoke /wayfinder with the map <map-url>, ticket <issue-url>. Invoke /wayfinder with the map <map-url>, ticket <issue-url>. Invoke /wayfinder with the map <map-url>, ticket <issue-url>.
No open tickets remain. The fog is pushed back far enough that the way to the goal is clear — the map is done. (The initial grilling may also surface no fog at all, in which case there was never a map to chart.) Recommend implementing directly, or using /to-prd to schedule a multi-session implementation.
npx claudepluginhub esonhugh/marketplace --plugin mattpocock-skillsBreaks down a loose idea into a sequenced map of investigation tickets (research, prototype, grilling) and drives them to resolution one session at a time.
Turns a loose idea into a git-tracked map of typed investigation tickets (research, prototype, grilling) and resolves them one per session. For work too fuzzy for a campaign, too big for a single intake item.