One dashboard tells me which Claude Code window needs me next

Most days I have four or five VS Code windows open, some on different projects and some on different changes to the same one, and each with a Claude Code conversation running. Those conversations stop and wait for me often: a permission prompt, a plan to approve, a stage that has finished and needs the next one starting.

They wait in whichever window I'm not looking at. I'd switch back to a project and find a build that had been sitting on a permission prompt, wanting to run a single command, for as long as I'd been away. Nothing told me it was stuck.

It's the problem a delivery lead has with a team. Work rarely stalls because someone is slow. It stalls in a queue, waiting for a review or an approval, and the board shows which column a ticket is in, not who it's waiting on right now. Once agents do the building, the person approving is the queue. So I added a dashboard to cf, my Claude Code plugin, that shows me what is waiting on me across every window.

Work waits on me more than it waits on Claude

Every change I make goes through the same stages: shape, plan, review, approve, build, verify, ship. I wrote about why in the first article on cf. Each change also gets its own branch, folder and pull request, so several can run side by side, which is covered in the second.

Take one change from 2 November, an exception rule for review accounts. It went from brief to pull request in two and a quarter hours. Claude was working for about an hour of that: ten minutes shaping, 25 planning, five reviewing the plan, ten building and five verifying. The rest was the change waiting for me. Its plan reviewer said ship at 11:05 and I approved at 11:39. At 11:43 the build prompt was ready, and I started the build at 12:11. Over an hour of that two and a quarter was two finished stages sitting there until I noticed.

The opportunity is to see only what needs me and be told the moment it does, instead of going round the windows working out what's next.

The dashboard puts whatever is waiting on me at the top

It runs on my machine and opens in a browser tab. The first thing on it is a list called Needs attention, in order of urgency:

"Asking you". A conversation has stopped on a permission prompt or a question. It appears as soon as the prompt does, names the project and says what's wanted, for example "Wants to use Bash: rerun the probe resolving the project's node_modules", with the full command underneath.
"Your move". A change is waiting on my decision: approve a reviewed plan, ship a verified change, or decide what to do once a change has used up its fix rounds. The command is there to copy.
"Finished, waiting for you". A conversation has finished its turn. If it was a cf stage, the item shows the next command.
"Ready for the next stage". A change whose next step hasn't been started.
"Check". A branch to rebase before it ships, or a merged change's folder to remove.

Each item has a link that opens that project in VS Code. The count is in the browser tab's title, so I can see it from any window.

Below the list, each project has its own section. Every open change shows its stage, the command for its next step, the model that step will run on, and the folder it's in. The dashboard warns me when main has moved since a branch was cut, and when two changes edit the same files or both add database migrations. Another view lists every change's folder and which ones can be removed once their pull request has merged, and an activity log shows each stage, approval, verify result and gate block as it happens.

Not everything I do in Claude Code is a change to a codebase. Some windows are drafting an article or using other plugins. Those conversations show up too. If one stops on a permission prompt or finishes its turn, it goes in the same list as everything else. cf only applies its gates to conversations working on a change, but I can still see when any of them needs me.

The data has already paid for one decision

There's history as well: tokens by model and stage, minutes per stage, gate blocks, and lead time from starting a change to opening its pull request.

The token breakdown showed me that builds were 55% of everything I used, and that on the first day Opus ran 84% of the build tokens. I moved builds to Sonnet, with Haiku for simple edits and Opus only when I approve it, and by 3 November Opus was 1% of build tokens.

That has cost nothing in quality so far. A fix round is verify sending a build back, and each approval gets a capped number of them. Of the eleven changes first built on Sonnet, none needed a fix round. Nine of the ten verified passed first time, and the tenth was sent back to be re-planned rather than fixed. The five built first on Opus needed ten fix rounds between them. Those five were also the earliest and the largest, so part of the gap is size, but nothing in the sample has given me a reason to put builds back on Opus.

Next to every next step, the dashboard now shows the model it will run on and why: Opus for planning and verification, Sonnet for builds and fix rounds, Haiku for simple edits. If a plan asks for an Opus build, I see the reason and decide, and the usage figures don't surprise me.

The numbers I care about most measure quality, and the dashboard tracks four:

Findings by category per week, from the plan reviewer and the verifier. If security or test findings keep appearing, the plans or the standards they work from need changing.
How often verify passes a change first time, and how many fix rounds a change needs.
How often the reviewer approves a plan on the first round.
Tokens per shipped change, and how much of that is Opus.

The baseline from the first five days: verify passed 10 of 15 changes first time and found 26 blockers in 29 runs. The plan reviewer approved 9 of 16 plans on the first round, and the 11 blockers it found were in plans, before any code existed.

It also compares the full lane with the light lane on each of these. The light lane is for small changes such as copy and config, with a shorter plan and a lighter review. It should ship them faster and cheaper without needing more fix rounds, and if its fix rounds go up, changes are going on the wrong lane. Only a handful of changes have been through the light lane so far, so that comparison has nothing to say yet.

I can export all of it to CSV for a spreadsheet or another reporting tool.

How it knows what each conversation is doing

cf already records every stage, approval and verification, but not what each conversation is doing right now. Claude Code runs hooks, small scripts that fire at set points in a session, and cf uses them to note when a conversation starts work, stops on a permission prompt and finishes its turn.

Each conversation gets a small file holding its folder, its change and its state, plus the tool call being asked about while a permission prompt waits. What I type to Claude is never stored, and the file is deleted when the conversation ends.

The dashboard reads those files and calls the same status script that sits behind /cf:status, so the two always agree. It only reads, and nothing leaves my machine unless I ask it to check pull request states on GitHub.

Teams using agents need the same view

Put a team of people in place of my VS Code windows and the queue looks the same. A plan waits for a tech lead to approve it, and a pull request waits for someone to review it. Both show on the board as in progress, because the board tracks columns, not who is holding the next step. As agents do more of the building, those approval points are where the time goes.

If you lead a team that works with agents, the list to keep is the one at the top of my dashboard: everything that is waiting on a person, with their name and how long it has sat there. That list gets long without anyone being slow. It gets long when nobody is looking at it.

The dashboard has only been running for a few days, so its effect on my own waits isn't in the log yet. When it is, the number I'll read first is the same one I'd read for a team: the longest a finished piece of work sat before anyone noticed.

Sources

Hooks reference, Anthropic, https://code.claude.com/docs/en/hooks