"Next up" board: navigate a generated backlog and launch the right skill for each ticket

[RyanSeanPhillips]

Re-scoped 2026-07-22. The original framing (a supervisor conversation monitoring live sibling sessions, with a two-layer digest protocol and completion detection) was solving the wrong problem. See Why the scope shrank at the bottom.

The actual problem

Running a structured workflow — the Matt Pocock skills are the motivating case — generates a lot of issues: decision tickets from /wayfinder, then a spec, then implementation slices from /to-tickets, each with blocking edges.

The operator gets lost in them. The need is navigation, not orchestration:

"I'd like an orchestration conversation that can see and keep track of all of these and help prioritise what conversation/issue I need to work through and finish next, and what skill that'd be."

This is also the answer to a harder problem: these workflows are difficult to drive if you don't already have good intuition for the process. A board that says "do this one next, with this skill" supplies that intuition.

Why this is computable, not a judgement call

/to-tickets publishes machine-readable structure:

• Every ticket body carries a ## Blocked by section — either blocking issue numbers/titles, or "None — can start immediately".
• Tickets are published in dependency order (blockers first) so edges reference real identifiers.
• Agent-grabbable tickets get the ready-for-agent label.
• Local-file mode writes .scratch/<feature-slug>/issues/<NN>-<slug>.md, numbered in dependency order.

So "what can I start right now?" is a graph query, not an AI guess: open issues whose blockers are all closed.

Proposed feature: a "next up" board

1. Ingest issues from the tracker (gh, already a dependency) and/or local .scratch/**/issues/*.md.
2. Build the DAG by parsing ## Blocked by.
3. Show three buckets: Ready now (unblocked), Blocked (with what's blocking them), In progress.
4. Rank ready tickets — prefer ones that unblock the most downstream work.
5. Name the skill for each, from ticket shape/labels:
   • decision ticket → /wayfinder or /grill-with-docs
   • spec-ready → /to-spec
   • ready-for-agent slice → /implement (+ /tdd)
   • bug → /diagnosing-bugs
   • untriaged → /triage
6. One click → one conversation, seeded with the ticket and its skill (launch_session already accepts a seed prompt and routes to a cockpit tile).

Why completion detection is no longer a blocker

The original scope needed live monitoring to know when a child was finished — a genuinely hard problem, since a quiet agent and a finished agent are indistinguishable.

This workflow already solves it: the agent closes the issue. The tracker is the shared state and the completion signal. No digest protocol, no mailbox, no polling of live sessions.

Relationship to Claude Code Agent Teams

Claude Code now ships agent teams (experimental, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1): a lead session spawns teammates with their own context windows, a shared task list, mailboxes, and automatic idle notifications.

That covers the parallel execution half — and it means cldctrl should not build its own supervisor loop. But it does not cover this issue, because:

• The Pocock pipeline's front half (/grill-with-docs → /wayfinder) is sequential and requires the operator in the loop. Claude's own docs say teams are the wrong tool for sequential work.
• Agent teams have no cross-session persistence — /resume does not restore teammates. A backlog board must outlive any session.
• On Windows there is no split-pane mode (tmux/iTerm2 only), so teammates share one terminal. cldctrl's cockpit tiles are the missing surface there.

Separate follow-up worth considering: surface agent-team state (~/.claude/teams/*/config.json, ~/.claude/tasks/*/, mailboxes) and the TeammateIdle/TaskCreated/TaskCompleted hooks in the dashboard.

Prerequisite to test first

Does seeding /<skill> into a fresh session actually invoke that skill? Step 6 rests on it entirely and it is unverified. Ten-minute test; do it before building anything.

Why the scope shrank

The first version of this issue proposed a supervisor conversation that spawned siblings, monitored them via a two-layer digest (server-derived + child-declared), addressed turns by pointer, and solved completion detection. That was:

• partly redundant — Claude Code Agent Teams now does the spawn/monitor/notify half natively;
• solving a problem this workflow doesn't have — the tracker already carries completion;
• not what was actually needed — the pain is navigating a large generated backlog, not supervising running agents.

[RyanSeanPhillips]

Prerequisite verified (2026-07-22): seeding /<skill> as a session's first message does invoke the skill. Confirmed three ways — positive, negative control (same prompt without the slash command → skill not loaded), and a verbatim quote from grilling/SKILL.md on disk. The one-click launch in step 6 needs no fallback.

Notification mechanism (avoids polling): a background watcher script tails a spawned session's JSONL and exits on a trigger — issue created/closed, /skill invoked, session idle. A background command exiting re-invokes the overseer, so it's event-driven rather than timed. Filtering happens in the script (zero tokens); a subagent runs only after a trigger, to digest the change into a few lines. Useful for the board's "in progress" column without holding transcripts in context.

Next: running this workflow manually on physiometrics first, with a session acting as overseer, to learn what the board actually needs before building it.