diagram-pane

What it does

Claude explains things with mermaid charts, but in a terminal you only see the raw code, and it scrolls away. Meanwhile the shape of the work (which files, which steps, what connects to what) lives only in Claude's context. diagram-pane opens a side pane that shows you both.

Pinned diagrams. Whenever a reply has a mermaid code block or an ASCII box diagram, it is pinned in the pane, newest first. Mermaid flowcharts are redrawn as boxes and arrows that fit a 60 column pane.
Live work map. Every few turns a cheap Haiku call asks whether the work changed shape. Only on yes does a fork of the session return a small graph of the files, components and steps it is working on, and the pane draws it. The node Claude is on right now is marked ▶.

Square boxes are files, round ones components, double ones steps or decisions. It sends nothing back to Claude. The output is for you only.

A mermaid chart in Claude's reply on the left, the same chart drawn as boxes and arrows in the pane on the right

Using it

The pane opens on its own in a terminal 144 columns or wider. Narrower than that, type /diagram once and it opens at any width. With fullscreen rendering it docks beside the transcript. In the classic renderer it sits above the prompt.

Ask for a diagram, something like explain the checkout flow with a mermaid flowchart, and it is pinned when the turn ends.
/diagram runs the gate now and redraws the map if the work changed.
/diagram force skips the gate and always redraws.

A plain question: the Haiku gate says the work kept its shape, so the map stays and no fork runs

Settings

everyTurns (3): turns between work-map checks.
maxPins (5): how many pinned diagrams the pane keeps.
DIAGRAM_PANE_EVERY (env): overrides everyTurns for one session, handy for a demo.

How it works

When a turn completes, the mod reads the transcript and pins any new mermaid or ASCII diagram it finds in Claude's replies.

Every N turns the gate runs: a Haiku call gets the current map, the files touched since that are not on it, and a digest of tool calls, and answers YES or NO. On YES, a fork of the session is asked for { title, nodes, edges } as JSON. A fork sees the whole conversation but cannot call tools, so it is cheap and served mostly from the prompt cache.

Charts and the map are laid out the same way: layers top to bottom, boxes wrapped to the pane's width. The map is saved per session, so it survives a hot reload or --resume. Pins are rebuilt from the transcript.

Limits

Only mermaid graph and flowchart charts are redrawn. Sequence, class, state and other types are pinned as raw code.
Every chart is drawn top to bottom, even graph LR, because a narrow pane has no room sideways.
Edges that skip a row or point back up are not routed. They are listed under the drawing with ⇢ and ↺.
ASCII diagrams are only picked up from plain code blocks (no language, or text), and shown as written.
The map check runs after a turn ends, not while Claude is working. Before the first reply there is nothing to fork, and /diagram says so.
The map is the model's own summary of the work, so it can include a step such as "run tests" beside the files.