Elite Product Demos

A recorded product demo is a film shot inside a working UI. It has a screenplay (script + shotlist), a camera operator (a deterministic autopilot driving the real interface), actors (the app's own animations and a drawn cursor), a recording rig, and an edit. Every phase below exists because skipping it produced a demo that flopped in front of real buyers.

Inputs — what the user provides

This skill does not design a product UI from scratch. It turns an EXISTING frontend into a film. Before starting, collect from the user:

1. A runnable frontend — a local mockup, staging build, or production app that renders

in a browser. It does not need to be complete: demo-only flows, seeded data, and staged AI responses are normal and expected additions, but the surfaces being shown must exist or be explicitly scoped as builds. If the user has no frontend at all, route them to elite-web-design first — this skill starts where a clickable UI ends.

1. Positioning context — what the product does for whom, who will watch the video

(archetypes), and any real sales-meeting signal about what lands. Interview for this; never invent it.

1. Brand assets — logo, the true brand colors (verify against the logo, not UI accent

tokens), voice/tone constraints.

1. Claim constraints — what may legally/honestly be shown or said (data provenance,

compliance, consent, roadmap-vs-shipped features).

Quick Reference

The Pipeline

0. INTAKE     Inventory the provided frontend: surfaces, wired vs. dead flows, how it's
              served, data seams. Map what the story needs against what exists; scope the
              gap as an explicit build list the user approves.
1. POSITION   Frame the story around what the product does for the buyer, in the buyer's
              words. Identify viewer archetypes. Weight beats by real sales-meeting
              signal, not copywriting instinct.
2. SCRIPT     Script + shotlist with hard timecodes, a causal-accounting rule, claim
              flags, and VO as pacing guides. One living document.
3. BUILD      Wire the demo flows into the frontend; write the shot-clock driver that
              clicks the real UI. Contracts between app and driver live in one cast sheet.
4. REHEARSE   Visible-tab runs with the owner watching. Every note becomes a driver or
              app change. Expect ~10 passes. The owner's cuts are the spec.
5. RECORD     Window-only ScreenCaptureKit capture with alpha, tab audio, and a
              camera-clean URL. ProRes master.
6. EDIT       Palmier Pro: ground-truth event extraction (cursor track + audio onsets),
              attention zooms, background float, speed ramps, VO, mix.

Principles that are not optional

Position before pixels. A demo that shows features in product-menu order is a tour; a demo that walks one believable person through one believable day is a story. Name the frame the product sells (e.g. "Find, Close, Manage → Build, Develop, Scale") and SPEAK IT ON SCREEN — chapter cards, outro line. Every viewer archetype (end user, management, executive) must see their payoff named, and the archetypes with the shortest attention must not be served last.

Real sales signal beats craft instinct. If live meetings show decision-makers lighting up for three specific things, those three things get screen time and everything else gets compressed — even when copywriting theory says otherwise. A beautifully argued beat about a feature nobody asked about is dead weight.

Causal accounting. Every number spoken or shown must be earned on camera. If the wrap-up says "six emails sent," the viewer watched six sends. If a reply arrives, the viewer watched the email that provoked it. And the opening screen should be the video's table of contents: everything queued there pays off in a later chapter. Audiences don't consciously notice this; they subconsciously trust it.

The demo is code. Drive the real UI with a deterministic shot-clock autopilot — never hand-mouse a take. Humans can't hit beats reproducibly and every retake costs the full video length. The driver is ~600 lines you'll iterate ~30 times; the take is free after that.

Rehearse with the owner; their edits are the spec. The person who will show this video to buyers watches rehearsals and cuts the recorded take. Capture every cut they make and why, then feed those numbers back into the next shot clock (see [pacing-canon.md](references/pacing-canon.md)). Scripted pacing consistently runs ~25% longer than what the owner ships.

Claims are flagged, not assumed. Any on-screen or spoken claim about data provenance, compliance, recording/consent, or capability status gets an explicit flag (F#) in the shotlist that the owner must resolve before recording. "It's on the roadmap" is a fine answer; discovering the problem after shipping the video is not.

One motion, one meaning. Each beat gets one intentional animation and at most one sound. Stacked animations split attention; stacked sounds (whoosh + chime + banner-chime within seconds) read as noise. See [motion-and-interactions.md](references/motion-and-interactions.md).

Working loop

1. Read [pacing-canon.md](references/pacing-canon.md) first — it recalibrates every

duration you're about to write.

1. Run frontend intake (top of [demo-driving.md](references/demo-driving.md)). Present the

gap list — what the story needs that the frontend lacks — and get it approved before promising beats.

1. Author the script/shotlist doc per

[story-and-shotlist.md](references/story-and-shotlist.md). Get the owner's sign-off on story and flags BEFORE building.

1. Create the cast sheet (single source of truth: names, numbers, integration contracts,

banned strings) and build app flows + driver per [demo-driving.md](references/demo-driving.md), applying [motion-and-interactions.md](references/motion-and-interactions.md) to every new beat.

1. Verify headlessly (browser asserts for every chain), then rehearse with the owner in a

visible tab. Fold every note back into driver/app/doc — keep all three in sync, with a dated changelog in the doc.

1. Record per [recording.md](references/recording.md). Import and finish per

[editing-palmier.md](references/editing-palmier.md).

1. After the owner's edit ships, diff their cut against your take and append the new

lessons to the pacing canon.

Bundled scripts (use these — don't re-derive)

Deterministic utilities in scripts/; each replaces expensive, error-prone in-context reasoning:

Attention keyframes come BEFORE length cuts — timings reference the demo-driver clock (free while the take is uncut; clip-relative thereafter, so they survive the owner's edits), and the plan of WHAT deserves a zoom comes from [interaction-design-and-flows.md](references/interaction-design-and-flows.md), not taste.

Cross-skill loading

• elite-copywriting — VO lines, hooks, objection pre-emption (collapse its phases for

demo scale, but never skip the awareness/sophistication check).

• elite-ux-strategy — persuasion structure, social proof placement, CTA framing.
• elite-brand-design / brand guidelines — the brand's REAL colors for cards and

outros. Never grab a UI accent token and assume it's the brand color; verify against the logo.

• elite-web-design — if the user has no frontend yet, that collection builds one;

this skill starts where a clickable UI ends.