| 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.
