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-01T00:00:00.000Z
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.
• - a on offending cards the camera rolls. Never film it and hope to cut around it.