Skip to main content
Cart

Guides

Harness Flow Graph: See the Pipeline Before It Runs

Neural-LLM Admin 4 min read
Harness Flow Graph static map of client entry, PreToolUse gates, and SessionStart steps
The static pipeline map from the real manifest — gates, matchers, agent spawn points.

A coding-agent session is not just a chat. Around every edit, the harness runs a pipeline: placement checks, save-time lint, approval reviewers, and agents that spawn on demand. The Harness Flow Graph is the static map of that pipeline — what will run, for any client, before you press enter.

TL;DR

NeedWhere
See the pipeline without running itProduct tile
Same map in the terminalpc workflow
Same map as an interactive graphPower Claude → Harness Flow / Design map
What this session actually didSession Flow Explorer — different surface
The diagram on this site is generated from the committed pipeline manifest. It is not a slide. If the harness adds a gate, the map must change with it.

The problem: you cannot debug what you cannot see

JSONL session logs tell you what happened after the fact. They do not tell you:

  • which PreToolUse matcher fires on Edit vs Write vs Bash
  • which steps are gates (they halt on failure)
  • which steps spawn agents
  • which host adapters are native, translated, or disabled

If you only have a transcript, you reverse-engineer policy. The Harness Flow Graph is the policy, drawn.

What the Harness Flow Graph is

A static map of the harness pipeline:

  1. Client entry — AGENTS.md and per-host leaves (Claude, Cursor, Copilot, …).
  2. Lifecycle events — PreToolUse, PostToolUse, SessionStart.
  3. Tool matchers — Edit, Write, Bash, Agent, and the rest of the declared set.
  4. Steps — format, policy inject, debug, tests, generated-file refresh.
  5. Gates — fail closed. Placement, approval, lint, PHPStan ignore, policy authoring.
  6. Agent spawn points — marked, not hidden as “magic later.”

Legend on the public diagram:

  • ◆ client
  • ▣ event
  • ◈ matcher
  • · step
  • ◇ gate (halts on failure)
  • ⊕ agents
  • ● end

That is the same vocabulary the terminal view uses.

Three surfaces, one engine

SurfaceCommand / placeUse when
WebHarness Flow Graph tileSharing the map, onboarding, docs
Terminalpc workflowSSH, CI notes, no GUI
VS CodeHarness Flow · 1 · Design mapClicking nodes, filters, zoom
All three are generated from the real pipeline manifest via `@cj-hurc/workflow-graph`. There is no hand-drawn twin that can drift.

How to read it (worked example)

Start at CLIENT ENTRY. Then read top-to-bottom by event.

PreToolUse · Edit

Before an Edit tool runs, the map shows gates such as:

  • structure / placement check
  • sensitive-edit approval (can spawn reviewers)
  • policy-authoring gate
  • PHPStan ignore / approval-dir guards

Only after those pass does ▶ tool runs.

If a land or save “mysteriously” blocked, this is the first page to open. The gate name on the map is the gate name in the deny.

PostToolUse · Edit / Write

After the tool, save-time lint is a gate. Then a list of post steps: debug, cache-bust, smoke, knowledge reindex, parity, generated refresh. Those are ordinary steps, not gates, unless marked.

SessionStart

Session boot is its own event: knowledge benchmark, periodic audits, PHPStan registry, CLAUDE.md coverage, bugflag drain, then ✔ session ready.

If a session “never quite boots,” SessionStart on this map is the checklist.

How this is not Session Flow Explorer

Harness Flow GraphSession Flow Explorer
TimeBefore / alwaysAfter one run
DataPipeline manifestSession transcript + overlays
QuestionWhat can run?What did run?
Mode in the UI1 · Design map2 · What ran and 3 · Path on map
**Path on map** (Combined) is the join: session legs drawn on the design pipeline. Dimmed nodes were never reached. Use that when you need both pictures at once.

Walkthrough: How to use Flow Explorer.

How to open it

On this site

  1. Open Power Claude.
  2. Jump to Harness graph.
  3. Read the web diagram. Flip the environment deck (Web / Terminal / VS Code) when the files exist.

In the terminal

pc workflow --view mermaid

In VS Code / code-server

  1. Open Power Claude.
  2. Open Harness Flow.
  3. Stay on 1 · Design map (not “What ran”).
  4. Use Graph for the DAG, Simple Flow for the human story, List if the canvas is busy.

Honesty notes

  • Numbers and node labels on the public diagram come from the committed manifest, not from a marketing illustrator.
  • Per-client adapter modes (native / translated / disabled) are real fields. Do not describe a disabled adapter as shipping.
  • The public try-it Flow Explorer uses synthetic sessions. Your real transcripts stay local.

Frequently asked questions

Is this a screenshot of VS Code?

The marketing tile includes a web rendering of the same graph. The VS Code panel is interactive. Both come from one generator. If they disagree, that is a bug, not a “stylized” version.

Does this send my repo to Neural-LLM?

No. The site diagram is the public pipeline map. Your project’s live graph is local.

Why would I care if I only use one host?

Because the same Edit/Write/Bash gates run regardless of whether the client is Claude, Cursor, or Codex. The map is how you stop treating “the agent refused” as weather.

What if a node says “undefined ref”?

That is an honest hole in the manifest, not a decorative label. Treat it as work: name the step or remove it.

Can I export it?

Terminal: pc workflow --view mermaid (when your Power Claude version documents that flag). In the explorer UI: Copy export.

Relation to `pc tree`?

pc tree is the session tree (what ran). pc workflow is the harness map (what can run). Do not mix the two in a postmortem.

Related

Independent third-party software. Not affiliated with Anthropic.