Wayfinder integration: MCP tools to read + dispatch Matt Pocock decision maps

[RyanSeanPhillips]

Why

Matt Pocock's skills (~20k stars) define a multi-session planning workflow — wayfinder — whose outer loop is exactly what cldctrl automates: launch a session, have it claim one ticket, resolve it, repeat. His tracker conventions are fully machine-readable, so cldctrl can become the mission-control layer for that workflow with no NLP and no coupling to his skill text:

• Map = one issue labeled wayfinder:map, fixed body sections (## Destination, ## Notes, ## Decisions so far, ## Not yet specified, ## Out of scope)
• Tickets = issues labeled wayfinder:<type> (research / prototype / grilling / task)
• Blocking = GitHub's native issue dependencies → frontier = open + unblocked + unassigned (pure API query)
• Claim = assign; resolve = comment + close + append a line to the map's decision index

Adoption angle: a lot of Claude Code users run this workflow; "cldctrl works your wayfinder maps" is a differentiator nobody else has.

Design

Layered so we're not coupled to one influencer's v1.x conventions:

• core/decision-map.ts — generic decision-map reader with pluggable adapters. Adapter CLD CTRL rebrand + cross-platform CLI/TUI #1: Pocock/GitHub conventions above (via gh api GraphQL for dependency edges). Adapter search_conversations only indexes user prompts, missing work by what was done #2 (later): his local .scratch/<feature>/ markdown tracker. Tolerant parsing; unknown sections/labels pass through.

Slice 1 — read_decision_map (MCP tool)

Input: project. Finds the wayfinder:map issue, parses sections, classifies child tickets into frontier / blocked / claimed (assigned+open) / decided (closed) with types. Returns structured JSON. Standalone value: any agent (and cc control) can see the map; cockpit can render it.

Slice 2 — dispatch_map_ticket (MCP tool)

Input: project, optional ticket number + agent (claude/codex/agy). Claims the ticket (assigns it), then reuses launch_session's web-first routing to open a cockpit tile with a prefilled prompt: "Claim and resolve ticket #N per /wayfinder…". Refuses blocked/claimed tickets. This is a concrete instance of #10 (driver reads → dispatches → verifies).

Slice 3 — nudges

computeNudges gains an idle-frontier nudge: map has ≥1 frontier ticket and no active session in that project.

Slice 4 — dashboard polish

Issues tab groups wayfinder tickets (map pinned, frontier highlighted); "work the map" button on the project.

Sequencing / gate

Build slice 1 first (useful alone, small: gh api + parser + MCP registration). Gate slices 2–4 on actually working one real map (planned: the cc control design itself) to validate the conventions in practice. Pin the adapter against mattpocock-skills v1.2.0 and re-check on plugin updates — his repo renames/deprecates skills over time.

Risks

• Convention drift upstream → mitigated by adapter layering + tolerant parsing
• Native issue dependencies need GraphQL (blockedBy); plain gh issue view doesn't expose them — verify API shape during slice 1
• Name collisions: his /handoff, /code-review overlap cldctrl vocabulary — docs should disambiguate

[RyanSeanPhillips]

Two observations from Matt's most recent video that sharpen this design:

1. His actual outer loop is copy-pasting ticket links into new conversations. That is precisely what dispatch_map_ticket (slice 2) automates — claim + open a primed session instead of paste-and-retype. It also suggests a lighter, generic quick win independent of wayfinder: paste any GitHub issue URL into the cockpit → new tile primed with that issue's context (title/body/thread via gh, prefilled kickoff prompt). Zero coupling to his conventions, useful to everyone, and it is the manual workflow he demonstrates.

2. He monitors parallel work via Claude Code's native agent view (left-arrow list of running agents). That's the pattern to beat, and it clarifies cockpit's edge and its gap:

• Edge: native agent view only sees agents inside one Claude Code process. Cockpit already spans separate sessions, projects, and vendors (Claude/Codex/agy).
• Gap: agent view gives at-a-glance state (working / waiting-for-input / done) for the whole fleet. Cockpit tiles show live terminals but there's no fleet-status strip — a compact per-tile state row (working / needs-input / idle / exited) would make "monitor lots of parallel conversations" a headline capability. Related: the existing subagent-viz roadmap item — native subagents write agent-*.jsonl alongside the parent session, so cockpit could surface his agent-view contents too.

Dispatch (slice 2) + fleet-status strip together = the wayfinder working phase with zero copy-paste: map → dispatch frontier tickets to tiles → watch states → review resolutions.