Video Storyboard

Video Storyboard

A repeatable process for the part of a video that decides whether it works: the narrative. Rendering executes the story; this skill designs it.

For cctop launch videos, this is the first half of the workflow:

1. Use this skill for story/script/storyboard/audit decisions.
2. Render through the repo video pipeline (cd video && ./build.sh launch for the launch cut).
3. After the user approves the rendered video, switch to $video-assets and publish with its confirmation gate. That workflow uploads cctop-launch.mp4, cctop-launch-720p.mp4, and a freshly generated cctop-launch-preview.avif together to the non-latest media-assets release.

For cctop product facts, audience, feature-fit judgment, and language choices, read PRODUCT.md before writing positioning or scripts. Use README.md for current public-facing claims and supported-tool lists.

It has two modes:

• DESIGN — build a video's story from scratch (product facts → approved storyboard).
• AUDIT — run the same lenses over a finished or draft video to find what's weak and how to fix it.

Pick the mode from the request. "Storyboard a video for X" → DESIGN. "Why does this video feel flat / make it better / review this cut" → AUDIT.

Everything here is built from frameworks that survived adversarial fact-checking. The frameworks are solid; many of the numbers floating around the industry are blog-grade rules of thumb. Where a guideline is directional rather than proven, it is marked [directional]. See references/frameworks.md for provenance, citations, and the specifics that were refuted (so you don't codify folklore).

---

The core idea

Most product videos fail the same way: they are a feature montage from the product's point of view ("here's the panel, here are the tabs, here are the themes"). They list capabilities instead of telling the story of a person whose problem gets solved.

The fix is one reframe and four moves:

1. The viewer is the hero; the product is the guide. (StoryBrand) The story is about them and their struggle, not about your UI.
2. Pick one spine and fill it — don't free-associate beats.
3. Connect beats by cause-and-effect (but/therefore), never by chronology (and then).
4. Engineer the opening for a muted, scrolling viewer — the first frame must earn the next two seconds.

---

Common failure modes (the floor-raisers)

These are the specific ways videos break, distilled from real reviews. They generalize — check for them in DESIGN (avoid) and AUDIT (catch). Pre-empting these is most of what makes a first draft good instead of a third.

1. The hook shows one thing and says another. The opening line promises tension ("which one needs you?") while the visuals say "all fine" (e.g. every status indicator green). The first ~1.5s of picture must depict the problem, not just the text — a muted scroller reads the image, not the words. Fix: put the problem-state on screen in frame one, with motion (the thing going wrong), before or under the line.
2. Action without payoff. You show the click / keypress / command, but never the result. The viewer feels the setup and never the relief. Fix: every action beat needs an after-beat — show the win (the session opened, the thing unblocked, the status flipping to good). This is the Story-Spine "until finally" / BAB "After," and it's the single most common missing beat.
3. Wrong-altitude reveal. You open on the product's fully-bloomed internal UI and point at an interior detail, instead of how the user first encounters it. Fix: start at the real moment of discovery (the menubar glance, the CLI prompt, the notification) and expand from there.
4. The "and then" tail. The back third decays into a feature montage — capability slide, and then another, and then another — with the hero gone. It's where momentum should peak before the CTA, and it sags. Fix: tie every late beat to the hero with "therefore (so you can trust it / use it with what you have)," compress, and cut vanity beats (theme galleries, spec lists) to a flash or nothing.
5. Product-as-hero in the belly. The bookends are viewer-centered but the middle becomes a spec sheet — the person disappears. Fix: keep a problem/person present even in capability beats.

What this skill is — and what it can't be

This skill raises the floor of the first draft and shortens each review loop — it guarantees the lenses get applied and the known failure modes get pre-empted, every time, even by a cheaper or distracted agent. That is its value, not out-reasoning a strong model on a single careful pass (it won't; a good model already knows this craft).

It deliberately does not encode per-video creative specifics — the exact pacing of a transition, which element pulses, what a mock screen shows. Those are taste, discovered by rendering a concrete draft and reacting to it; hard-coding them would overfit the skill and make it brittle. Capture patterns here; leave the particulars to iteration on the actual cut.

---

DESIGN mode — the 6-stage pipeline

Each stage takes one artifact and produces the next. Don't skip ahead; a weak positioning statement poisons every downstream stage. Keep each artifact short — a video is 20–40 seconds, not a feature doc.

Stage 1 — Position · in: product facts + audience · out: one-paragraph positioning

Write the story's frame before any script, using StoryBrand: the viewer is the hero, the product is the guide that helps them win. Name three things:

• Who the hero is (be specific: "a dev running several AI coding agents at once", not "developers").
• What they want and what's in the way (the external problem and the internal feeling — frustration, loss of control, wasted time).
• The transformation: the before-state → the after-state the product enables.

If you catch yourself describing the product's features here, stop — you've made the product the hero. Rewrite from the viewer's chair.

Stage 2 — Message spine · in: positioning · out: a chosen structure, each step filled

Choose ONE spine and write a sentence for each step:

• Before-After-Bridge (default for 20–40s) — Before (the painful current state) → After (the desirable future) → Bridge (the product as the thing that gets you there). Best for "storytelling in tight spaces."
• PAS — Problem → Agitate (make the cost of inaction felt) → Solution. Use when the pain is sharp and relatable.
• AIDA — Attention → Interest → Desire → Action. Use when a hard CTA/conversion is the goal. (AIDA is a conversion spine, not a story arc — don't force it into acts.)

Stage 3 — Beat sheet · in: spine · out: 4–7 ordered beats

Generate beats with the Pixar Story Spine as a prompt ("…every day… until one day… because of that… until finally…"), then run the But/Therefore test on every seam: each beat must follow from the last with a "but" (tension) or "therefore" (consequence). If the only word that fits between two beats is "and then", you have a list, not a story — cut or reorder until causation holds. This single test is the fastest way to find a flat middle.

Stage 4 — Script · in: beat sheet · out: on-screen-text / VO script with timecodes

Write the words and the timing. Hard requirements, because the median viewer is scrolling with the sound off:

• The first frame must work muted and lead with motion, not setup. No cold logo, no slow fade-up on an empty stage. Open in the hero's problem.
• Answer "what is this / why do I care" by ~second 3–5. [directional] Slow build is the #1 retention killer.
• End on a clear payoff and one CTA (where to go / what to do).
• Track the opening with hook rate = 3-sec views ÷ impressions once it ships. [directional]