Introducing ccgrapher

Agent workflows get written as a straight chain, because that is the order the steps occurred to you. Almost none of them are actually shaped that way. ccgrapher finds the difference — and, more importantly, finds the checks that were never really checking anything.

The failures it catches

A verification step that grades its own work will pass. A fan-in with no count guard will report success even when one of its branches died silently — the result looks complete, and nothing tells you it isn't. Those are the two failures worth the install: they are invisible precisely because the run goes green.

ccgrapher also flags concurrent steps that write the same file, inputs that nothing supplies, and results piling into one step faster than it can hold them.

Why it can tell

You declare what each step reads, not what happened before it. That single discipline is what exposes the fake edges: an edge only exists if real data passes along it, and you cannot honestly write down what step seven consumes and still believe it was waiting on step six.

Delete the edges that carry nothing and the graph goes wide instead of tall. In one real session — nine pull requests shipped one after another — six of them had never been waiting on anything. Same work, five waves instead of twelve. The speed is the bonus; the reason to run it is the checks it repairs.

Using it

There is a Claude Code skill in the repo. Symlink it and your agent checks the shape of any plan of five steps or more before executing it, then runs the independent parts together. Or use the CLI directly:

npx @ccgrapher/cli lint your-workflow.yaml

There is more at ccgrapher.artfusion.com, and the source is Apache 2.0 at github.com/artfusion/ccgrapher. It is early — v0.3.0 — and the failure taxonomy is the part we most want argued with.