Feature request: Built-in workflow visualizer — preview each step and its properties before running a workflow

Problem

When I author or run a dynamic workflow (the Workflow tool / .claude/workflows/*.js), there's no built-in way to see the shape of the workflow before it runs. Workflows can fan out dozens of agents and spend a lot of tokens, so kicking one off blind — without a clear view of its phases, the agent calls in each phase, and how they're structured (fan-out / concurrent / pipelined) — is risky and hard to reason about.

/workflows shows live progress while it runs, but I want a static, dynamic-to-explore preview before I commit to a run.

What I want

A built-in workflow visualizer: a lightweight parser that reads the workflow definition and renders each step with its properties, so the user can inspect the structure up front. Ideally interactive/dynamic — expand a phase to see its agents, each agent's label, model, structured-output schema, etc.

Concretely it should surface:

• 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: fan-out (multiple agents in a phase), concurrent (inside parallel(...)), pipelined (inside pipeline(...)), and a marker for agents requesting structured output (schema:).
• Summary counts: agents, phases, parallel/pipeline primitives.

Workaround I built

I wrote a /workflow-viz skill — a zero-dependency Node parser that reads a workflow .js and prints an ASCII flowchart of phases, per-phase agent calls, fan-out/concurrent/pipelined tags, and structured-output markers, plus a footer with agent/phase/primitive counts. It works well and has made workflows far easier to reason about before running them.

It's a regex parser (no AST), so it doesn't resolve nested control flow precisely — a first-party version with access to the real workflow runtime could render the exact branch topology and properties, and ideally do it interactively rather than as a one-shot ASCII dump.

Why it matters

Workflows are powerful but opaque to author and expensive to run. A built-in "preview before run" visualizer would make the orchestration model much easier to understand, catch mistakes before spending tokens, and lower the barrier to writing good workflows.