/teaser-video

name: teaser-video
description: Film, cut, and deliver a short teaser/demo video of any app by driving it with Playwright and editing with ffmpeg - storyboard, authenticated capture, PII review, animated title cards, MP4 + GIF. Use for "make a teaser", "record a demo video", "product launch video", "screen recording for the README".
user-invocable: true
version: 1.0.0
updated: 2026-08-01
portable: true
requires:
  - node >=24
  - npm packages (installed into a scratch dir, not the project): playwright, ffmpeg-static, pngjs
  - a Chromium/Chrome channel available to Playwright
files:
  - SKILL.md
  - reference/package.json
  - reference/login.js
  - reference/scout.js
  - reference/rig.js
  - reference/build.js
  - reference/cards.js
  - reference/jitter.js

Teaser video

Produce a launch-quality teaser (~30-45s) of a running app: storyboard it, film it by driving the real UI, cut it with ffmpeg, and hand back an MP4 plus a GIF for the README.

The output must look like a product video, not a screen recording. The difference is direction - staging, framing, and rhythm - not resolution.

Reference implementations live in `reference/`; they are working ESM modules, not pseudocode. Set up in a scratch directory - never inside the project:

cp -r <skill>/reference/* "$SCRATCH/" && cd "$SCRATCH" && npm install
export TEASER_BASE_URL="https://the-app.example.com"

`reference/package.json` declares `"type": "module"` and the three dependencies. Every script reads `TEASER_BASE_URL`, so nothing is hardcoded to one app.

Before anything else: the two hard rules

**1. Never trigger real-world side effects without explicit, itemized consent.**

Filming a real app means clicking real buttons. Some of those send email, post publicly, charge money, or submit forms to third parties. Before you touch the app:

• Enumerate every action in your storyboard that leaves the machine.
• Tell the user exactly what each one does and how many times, then get

agreement on the count.

• Prefer a mode that stops short of the irreversible step (a preview, a

dry-run, a confirmation gate you can film and then decline).

There is no such thing as a read-only probe against a live system. A "diagnostic" click that lands in an already-running session fires for real. If you are debugging why an action did not work, assume your next click *will* work, and be ready for it.

If something fires that you did not intend: stop the process at its source immediately (kill the session/worker, not just the UI button, which may not take effect), verify the stopped state by reading it back, and tell the user plainly in your final message - count included.

**2. Assume every frame is public and full of PII.**

Real accounts carry names, emails, addresses, and documents. Decide the policy with the user up front:

• **Frame around it** (default) - compose shots that exclude identity. Crop

persistent chrome (sidebars, avatars, account menus) at the ffmpeg stage.

• **Hide before rolling** - `page.evaluate` a `visibility: hidden` on offending

cards *before* the camera rolls. Never film it and hope to cut around it.

• **Use a seeded demo account** - cleanest when one exists.

Review every frame of the final cut at full resolution before delivering. Not the contact sheet - the frames.

Workflow

1. Scout and storyboard

Take authenticated screenshots of every candidate screen first (`reference/scout.js`). Look at them. Then write a storyboard table: beat, shot, what the viewer should *feel*, and length. A shot with no assigned job gets cut before it is filmed.

Arc that works: tension (the problem) → reveal (the product) → proof (it really does the thing) → scale (the results) → trust (where it runs) → close.

Note in the storyboard which screens hold PII and which are safe.

2. Stage the set

Curate before rolling, never after:

• Pick views where the data looks its best - full charts, active lists,

recognizable names, non-zero counts. Never film a spinner, an empty state, or a half-rendered chart.

• Set UI state deliberately (panel widths, collapsed/expanded, filters, scroll

position) via `localStorage` in an init script or a pre-roll `page.evaluate`.

• Dismiss toasts, banners, and cookie bars off-camera.
• Let data settle: `networkidle` plus a few seconds.

3. Film

Use **CDP screencast** (`Page.startScreencast`), not screen recording. It captures the page off-screen at ~100fps, so nothing the user is doing appears in frame and the machine stays usable. Playwright drives; CDP films. `reference/rig.js` implements it.

• One subject per shot. Frame the thing, not "the whole app".
• Camera moves come from **scripted eased scrolling inside the page**

(`cameraScroll`), never from a filter. See the zoompan warning below.

• The cursor is an actor: use the injected SVG cursor (`cursorClick`) that

glides with easing and dips on press, or hide it. No idle drift.

• Rehearse each take, extract frames, look at them, adjust, then film for real.

**Filming an external window** (a browser the app itself opens, a desktop app) needs OS capture - `gdigrab`/`x11grab`/`avfoundation` (`recordDesktop` in the rig). This captures *everything on screen*, including the user's own work. Warn the user, ask them to step away, and review the result frame by frame; delete it if it caught anything private.

4. Title cards

Animated HTML/CSS filmed in-browser, not static images. Inject the card markup into a blank page **on the app's own origin** so its web fonts and palette resolve, then screencast it. Pull the real display font off the live page (`getComputedStyle`) and pin a known-good mono stack rather than sniffing one.

Match the app's motion language (its own easing curves and durations). Load the `frontend-design` skill before designing them if the project has no established card style.

5. Cut

`reference/build.js` normalizes each segment to a common size/fps, then crossfades the chain. Keep cuts every ~