| name | workflow-viz |
| description | Render a terminal flowchart of a Claude Code dynamic-workflow .js file — phases, per-phase agent calls, fan-out / concurrent / pipelined structure, and structured-output markers. Use this skill whenever the user runs /workflow-viz or asks to "visualize a workflow", "show the workflow flowchart", "diagram this workflow", or "map out .claude/workflows". Pure bash wrapper around a Node parser — do NOT reason about the workflow yourself. |
| argument-hint | [workflow.js | dir ...] (default: .claude/workflows) |
workflow-viz Skill (global)
Thin wrapper over a zero-dependency Node parser (scripts/viz.js) that reads a
dynamic-workflow .js file and prints an ASCII flowchart in the terminal.
What it shows
- The workflow
name + description (from export const meta).
- Each phase from
meta.phases, in order, with its detail.
- The
agent() calls grouped under their phase, with each agent's label.
- Structure tags inferred from the source:
⇉ fan-out (multiple agents in a
phase), ‖ concurrent (inside a parallel(...)), ⇢ pipelined (inside a
pipeline(...)), and ⊟ for agents that request structured output (schema:).
- A footer with agent/phase counts and
parallel/pipeline primitive counts.
Usage
/workflow-viz [TARGET ...]
- No argument → visualizes every
*.js in ./.claude/workflows.
- A file → visualizes that one workflow.
- A directory → visualizes every
*.js inside it.
- Multiple targets are allowed and rendered one after another.
How to execute
Run exactly this, replacing $ARGUMENTS with whatever the user typed after
/workflow-viz (may be empty):
node ~/.claude/skills/workflow-viz/scripts/viz.js $ARGUMENTS
Then print the command's output verbatim. Stop.
Do NOT
- Do not parse or interpret the workflow yourself — the script does it.
- Do not open the workflow
.js files with Read; just run the script.
- Do not offer next steps, summaries, or analysis of the workflow's logic.
- Do not split the invocation into multiple bash calls.
Implementation note
scripts/viz.js is an intentionally lightweight regex parser (no AST / acorn).
It keys off meta.phases and the textual agent() / parallel() / pipeline()
calls. It does not resolve nested control flow precisely — the ‖/⇢ tags mark
which phases sit inside a concurrency primitive, not the exact branch topology.
For the dynamic-workflow format this is accurate enough; if a future workflow
defies the regex (e.g. computed phase names), upgrade the parser to an AST walk.
