# Update / add infographics prompt (Opus 4.8)

A prompt to refresh stale architecture diagrams and add new infographics across the
videoclaw documentation. Authored with the `prompting-opus-4-8` skill (enumerated scope,
parallel fan-out, verify-against-code, plan-gate before spending image-gen quota).

Routes ALL diagram changes through the Mermaid source of truth and the Go Bananas Pro
renderer — never hand-edits the generated JPGs.

Run at **xhigh** effort.

```text
You're working on videoclaw-v3 (the `vclaw` CLI). The documentation's architecture diagrams
have fallen behind the code, and several docs that would be much clearer with a diagram don't
have one. Refresh every stale infographic AND add new ones where they genuinely help a reader
understand the system. Every diagram must match what the code actually does today.

How diagrams work in this repo — follow this exactly:
- The Mermaid sources in docs/DIAGRAMS_SOURCE.md are the SOURCE OF TRUTH. The images under
  docs/assets/*.jpg are GENERATED from those Mermaid blocks via the Go Bananas Pro model.
- NEVER hand-edit a JPG. To change a diagram, edit its Mermaid block in DIAGRAMS_SOURCE.md,
  then regenerate the image. Use the go-bananas:workflow-diagrams skill (Go Bananas Pro) to
  render Mermaid -> image, and save the output to the correct docs/assets/ path.
- Embed/reference each rendered image in the doc(s) that should show it.

Ground truth for WHAT each diagram should depict is the code, not your memory or the current
prose: src/cli/ and src/video/ (the layers), src/video/cli-schema.ts COMMANDS, the handlers,
schemas/video/, src/video/pipeline-manifests/ and provider-platform/, and the docs in docs/.
Read these to confirm the real architecture before drawing it.

Scope — review each of these as a candidate diagram, update if stale, create if missing and
useful (treat the list as exhaustive, don't generalize from the first few):
1. System layers: CLI dispatch -> src/video domain -> provider-platform routes -> schemas.
2. Project lifecycle on disk: init -> brief -> storyboard -> assets -> review -> publish, with
   the readiness / plan / produce(execute) runtime layer that sits between assets and review.
3. The two production modes (storyboard vs director) and the director storyboard-approval gate.
4. The studio front-door goals and how a goal maps to the underlying vclaw commands.
5. Provider routes and adapters: Veo (Flow/UseAPI/Omni), Seedance, Runway, Dreamina — native
   in-process transports vs useapi adapters, and the no-silent-fallback rule.
6. The review-state ladder (missing | current | stale) and where it flows.
7. The auto-chain / chain-from-prev execution flow.
8. The AI-filmmaking 3-template chain: character sheet -> storyboard grid -> Seedance variants.
9. The audio platform backends (narrate/dialogue/sfx/soundtrack -> backend registry -> assemble).
10. The motion-overlay pipeline and the overnight batch queue.
11. The preview/review portal surfaces.
12. The skill composition / front-door routing graph.
Also scan docs/ for any existing diagram already referenced by a doc and confirm it's current.

Spawn parallel subagents — Opus does not fan out on its own. Dispatch subagents to inspect
independent slices concurrently (existing diagrams + their DIAGRAMS_SOURCE.md blocks; the
layer/architecture truth; the lifecycle/runtime truth; the provider-route truth; the docs that
lack a helpful diagram), and keep working while they run. Each returns: which diagrams are
stale (and exactly what's wrong vs the code), and which docs would benefit from a new diagram
(with the concept it should show).

Work in two passes:
1. AUDIT (parallel): produce one consolidated list — stale diagrams to regenerate, and new
   diagrams to add (each with target doc, the concept, and a draft Mermaid block). Show me that
   list plus a rough count of image generations it implies, and pause once for me there. Image
   generation via Go Bananas costs quota — I want to approve the set before you render. Where a
   diagram is already accurate, say so and leave it untouched.
2. BUILD (after I approve): for each approved item, write/fix the Mermaid in DIAGRAMS_SOURCE.md,
   render it with the go-bananas:workflow-diagrams skill, save to docs/assets/, and embed it in
   the right doc(s) (and the matching docs-site/ page if one exists). Keep a consistent visual
   style across all diagrams so they read as one set.

Conventions and guardrails:
- Match the existing diagram style and the docs' voice; don't restyle docs you're only adding
  an image to.
- Keep all Mermaid in docs/DIAGRAMS_SOURCE.md (one block per diagram, clearly labeled) so the
  source stays regenerable; never leave a JPG without its Mermaid source.
- Run `npm run check:cleanroom-docs`, `npm run build`, and `npm test` before declaring done;
  keep them green.

Verify before you claim done. Before reporting a diagram as correct, confirm what it depicts
against the actual code you read this session, and confirm the rendered image is embedded and
displays in its doc. If you couldn't render one (quota, tool error), say so plainly rather than
leaving a broken reference.

When you finish, lead with the outcome — how many diagrams you refreshed, how many you added
and to which docs, and that the build and doc checks pass — then the per-diagram detail. Plain
sentences, each diagram and its doc its own clause.
```