Motion Showreel

Turn an idea into a short video centered on graphics, text, or interface animation, delivering an MP4 and source code capable of recreating it.

Principle: The page exposes a deterministic

render(t)

, a script captures each frame, and ffmpeg assembles the MP4. Music and sound effects are synthesized in code and share a single

timeline.js

with the visuals, so beat synchronization can be accurate to the frame.

What makes a great piece: Density of change, quality of movement, one memorable idea, and the relationship between sound and visuals usually determine how a piece feels. But exactly how it moves and how much it moves depend on style and content; not every video needs multiple cameras, springs, and sound effects everywhere. Only a few global constraints apply (see “Bottom Lines”); everything else is a starting point for the model, not a ceiling.

Scope

What the user wants	Use this Skill?
Product promo videos, motion showreels, UI animation, kinetic typography / beat synchronization, logo reveals, intros, looping motion graphics	✅
A green-screen character generated by a video model, combined with a code-built scene, large type, and motion	✅ The character is provided by the user ( `references/formats.md` Class H)
A multi-minute video with a narration script or article that explains the content sentence by sentence	❌ Use `web-video-presentation`
Webpages, landing pages, interactive prototypes, static visual comps	❌ Use `web-design-engineer`
Realistic human performances, live-action textures, editing existing footage, or using a video model to generate the visuals directly	❌

Duration: Best suited to 5–60 seconds. Music-driven videos without narration can run for around 2 minutes, such as

mixed-media-era

era-retrospective pieces. When the duration exceeds 60 seconds, produce and inspect each section separately, and explain the rendering and review costs before starting. Videos requiring narration are outside this Skill's scope.

Opus's Strengths and Default Pitfalls

Strengths: A single file can mix Canvas, SVG/DOM, WebGL, Three.js, and even switch media for each segment. Movement can be calculated precisely with formulas, including closed-form springs, beat grids, and subframe motion blur. Sound and visuals read from the same timeline. Opus can autonomously “render stills → inspect images → revise” for extended periods. It has strong aesthetic judgment: a single instruction such as “go all out” may produce something stunning.
Default pitfalls: Without constraints, visuals tend toward dark backgrounds, centered large type, everything fading in together, purple-blue gradients with glow, and a static camera. Soundtracks tend toward A-minor four-on-the-floor rhythms, an impact and crash on every downbeat, and a bell on the final beat, making several pieces sound like the same song. Therefore, find the right references for both picture and sound, and define the style and forbidden list. However, constraints must not be fixed in advance: this Skill's style and technique libraries are starting points that can be adapted, mixed, or customized whenever the theme requires it.
Not good at: Realistic people, complex hands, cloth, or hair; anything requiring true physical accuracy; or photorealistic products unless the user provides a model or image. In these cases, use a stylized approach or switch to a green-screen character combined with a code-built scene.

Workflow

0 Environment check (once)
1 Clarify everything in one go ──────── Ask only what cannot be inferred
2 brief.md ──────────────────────── References → purpose + style → Reel Read → beat grid + storyboard + forbidden list
3 Style frames ──────────────────── 🛑 The only pause: style set → 1 direction, 3 frames; style not set → 3 directions, 1 frame each
4 Production ───────────────────── Timeline → shot by shot → still self-check → determinism check → proxy → final
5 Sound (optional) ──────────────── Code synthesis / user track / no audio
6 Acceptance ───────────────────── Technical checks (programmatic, must all pass) + review (inspect frames, list issues, final user approval)
7 Delivery

Working directory: Create

<slug>/

under the user's current directory and place all files inside it:

brief.md

index.html

motion.js

timeline.js

score.mjs

score.tone.js

according to the scaffold's

--audio

option,

build.sh

fonts/

assets/

audio/

qa/

, and

out/

Step 0: Environment

On first use, run

sh <skill>/scripts/setup.sh

. It installs Playwright and Chromium, then runs

check-env.mjs

. Node 18+ and ffmpeg are required. If either is missing, explain how to install it; do not install system software on the user's behalf. The tools include tests:

cd <skill>/scripts && npm test

Step 1: Clarify Everything in One Go

Ask in a single message, with no more than 5 questions. Skip anything already answered in the request. If the user says “you decide,” use all defaults and note them in the brief.

What to ask	Default
Topic and assets: logo, product screenshots, copy, brand colors, fonts	Use only facts supplied by the user; do not invent features, data, or customers
The one sentence or image the audience should remember	Derive it from the topic
Duration, aspect ratio, platform	15 seconds · 1920×1080 · 30fps; use 1080×1920 for vertical platforms; UI animation may use 60fps
Style: Is there a specified style, reference video, or screenshot?	If not, present 3 directions in Step 3 and let the user select based on the rendered frames
Sound: silent / code-synthesized / user-provided track that must be licensed for commercial use	Code-synthesized

If the user provides a reference video, first run
```
inspect.mjs sheet <ref> --cells 30
```
to review the whole piece,
```
inspect.mjs grid <ref> --strips
```
to identify cut points and the beat grid they land on, including BPM candidates, how many beats each segment spans, and the continuous frames of each transition, and
```
inspect.mjs heat <ref>
```
to see where and how much movement occurs within each segment. Record the measured values in the brief's reference section. Learn the structure and techniques only; do not copy the assets.

If the user provides a track, first run

audio.mjs beats <track> --out <slug>/audio/beats.json

Verify any product, brand, or technical term that appears in the visuals if it is uncertain.

Hands-off mode: Enter hands-off mode when the user says “go all out,” “surprise me,” or provides only a topic with no other requirements. In this mode, observe only the bottom lines and technical pipeline, and independently determine the style, structure, and techniques. The Skill's style library may be left unused entirely. You must still write the brief, which keeps your creative decisions controllable and reproducible, and you must still present 3 directions in Step 3.

Step 2: brief.md

Find references first: Before writing, select 1–2 reference works for this particular topic and purpose. These can be film title sequences, advertisements, games, motion pieces, or design movements. In the brief, document what to learn, such as composition, pacing, shot grammar, color logic, and music structure, and what not to learn, such as characters, specific shots, melodies, logos, or font files. References are more effective than any set of rules at raising the quality ceiling.

Then consider three candidate structures: For example, a journey, a before-and-after contrast, a countdown, one thing becoming another, or a single continuous take. Describe each in two or three lines, select one, and explain why. The first idea that comes to mind is often a cliché for the chosen style.

Select the purpose and style separately:

The purpose, meaning what is being made and how it is structured, is defined in
```
references/formats.md
```
; read only the relevant section.
The style, meaning how it looks, moves, and sounds, starts with
```
references/styles/INDEX.md
```
; then read only the selected 1–2 style files. A style may be used directly, adapted by replacing one or two rules, mixed as a primary and secondary style or by switching media between segments, or customized using
```
styles/_template.md
```
. Keep the style rules intact, but derive the story, shots, and structure from the user's topic rather than carrying them over from another video. Every style file has “Recognition Cues” and “Most Clichéd Version” sections. Select 2–3 cues appropriate to the topic, including at least one that is not clichéd, and state in the brief which clichés have been overturned or why they have been retained. When the user chooses a style, it should be recognizable at a glance, and two or three cues are sufficient.
Consult
```
references/craft.md
```
as needed for the technique library.

Write the brief using

references/brief-template.md

. The core is:

yaml

Reel Read:
  format: [purpose, type from formats.md]
  benchmark: [reference work · what to learn · what not to learn]
  structure: [three candidate structures → selected one and why]
  style: [style from styles/, including modifications, a mixed approach, or custom rules]
  signals: [selected 2–3 recognition cues and why; which clichés were overturned]
  takeaway: [the sentence or image the audience should remember]
  hook: [what happens during the first second]
  signature: [memorable moment: at which second and through which technique]
  palette / type / motion / camera / texture: [concrete values based on the selected style]
  sound: [silent / synthesized (sound reference, rhythm, harmony, instrumentation, curves; see Section 2 of sound.md) / user track (BPM, drop)]
  forbidden: [forbidden list for this video]

Next, add the beat grid and storyboard to the brief: Define the BPM and number of bars first. Use one row per shot and specify

time-signature range | visual, including exact copy | movement | camera | sound | transition

Even if the user says only “go all out,” translate that into the concrete constraints above; otherwise the result is a random draw.

Step 3: Style Frames (🛑 The Only Pause)

Create the project:

sh <skill>/scripts/scaffold.sh <slug> [--audio synth|tone|layer|none]

. The default is synth, meaning the first synthesis tier. The scaffold copies only the selected score and sets

AUDIO=

build.sh

accordingly. The starter is only for validating the pipeline; both the visuals and copy must be replaced. Write

timeline.js

first.

A. The user has already defined the style, either directly or through a clear reference:

Use real code to build the hook frame, signature-moment frame, and end frame with the final palette, fonts, and copy.
Run
```
render.mjs <slug> --still 0.6,7.2,14.5 --sheet
```
and inspect the result yourself. Fix obvious issues before showing it to the user. If the signature moment depends on motion, also produce a 2–3-second sample with
```
--start --duration
```
.
Send the user the Reel Read summary, storyboard overview, and style frames, and ask, “Is this the right direction?”

B. The user has not defined the style, including hands-off mode: Present 3 clearly differentiated directions, following the rules in

styles/INDEX.md

A: Fits the topic or brand.
B: Uses a different visual language from another group.
C: Is bold, using a custom, mixed, or structurally bold approach; at least one direction must not come directly from the library.

For each direction, write a mini Reel Read in 3–5 lines covering the style, reference, signature moment, and music direction. Render one representative keyframe using real code. Place the three direction pages in the same project and switch between them with

?dir=a|b|c

. Directions B and C only need to support this single keyframe and do not have to become playable videos.

Run

render.mjs <slug> --directions a,b,c --at 14.5,2,0

to render the three frames in one pass and compose them into a labeled

qa/directions.png

. Send it to the user and ask, “Which one should we use, or how should we combine them?”

In both cases, actually wait for the user's response before production begins. If the user previously waived confirmation, select a direction independently, document the reason, perform a self-review, and continue. At delivery, include the unselected alternatives so the user can request changes later: in Case B, include

qa/directions.png

; in Case A, briefly describe the other two possible directions.

Step 4: Production

Before production, read

references/stack.md

for the page contract, determinism, and technology-specific pitfalls. Consult

references/recipes.md

when an established implementation pattern is useful.

Put every timing point in
```
timeline.js
```
; both the page and
```
score.mjs
```
import from it. Record the shot list in
```
SHOTS
```
so motion can be reported per shot during acceptance. Record intentional holds in
```
HOLDS
```
, such as a final title card expressed as
```
[[b(36), DUR]]
```
, and intentional breathing room on downbeats in
```
DROPS
```
. The acceptance tools read these values. To align a transition with the beat, reverse-calculate its start with
```
revealOn(beat, transition duration, reveal point)
```
so that the frame on which the new visual appears lands exactly on the beat.
Build the shots one at a time. For each shot, render stills at the beginning, middle, and end. Use
```
inspect.mjs strip
```
to inspect consecutive frames for fast motion.
Run the determinism check
```
render.mjs <slug> --determinism
```
and fix any failures first.
If the video is 30 seconds or longer or rendering is slow, first produce a low-resolution proxy with
```
--size 960x540 --out out/proxy.mp4
```
.
Produce the final video: First set
```
FPS
```
,
```
SIZE
```
,
```
AUDIO
```
, and
```
LOOP
```
at the top of
```
build.sh
```
according to the brief, then run
```
sh <slug>/build.sh
```
. It builds the soundtrack, runs the determinism check first, and refuses to render if it fails; then it renders, runs the text-bounds check, which produces review material without blocking the build, and finally runs technical checks using the same specifications, with the duration taken from
```
DUR
```
in
```
timeline.js
```
. The
```
--subframes
```
,
```
--dpr
```
, and
```
--grain
```
options can be appended as needed for the style. These options can multiply the rendering time, so report the estimate before starting.

Hard rules:

The visuals must depend only on
```
t
```
: do not use
```
Math.random
```
,
```
Date.now
```
, rAF, timers, or CSS animations, and do not preserve state between frames.
Wait until all fonts and assets have loaded before setting
```
READY = true
```
; self-host fonts inside the project.
Derive the layout from the width and height returned by
```
stageSize()
```
; do not hard-code pixel dimensions.

Step 5: Sound (Optional)

Read

references/sound.md

. The sound direction, including its reference, rhythm, harmony, instrumentation, and curves, is defined in the brief in Step 2; implement it here. Choose a tier according to the style:

Tier	Implementation	Best suited for
Tier 1 · Built-in synthesis	`score.mjs` , a synthesizer in Node for drums, hand percussion, bass, pads, plucks, marimba, celesta, kalimba, organ, vocal pads, FM, ambient noise, sound effects, sidechain, reverb, and lo-fi processing, with zero dependencies	Electronic, UI, chiptune, ambient, lo-fi, handmade and toy-like work, and most motion pieces
Tier 2 · Tone.js	`score.tone.js` , rendered offline in a headless browser with Tone.js: sampled instruments, convolution reverb, and richer synthesizers and effects	Styles requiring realistic instruments, spatial depth, or a cinematic sound
External track	Music supplied by the user, either their own, licensed, or generated by an AI music service	Users who already have a soundtrack

Build with

audio.mjs build <slug>/score.mjs

score.mjs

using

score.tone.js

; either produces

audio/music.wav

at −14 LUFS.

For a user-provided track, first run
```
audio.mjs beats
```
, using librosa automatically when available, align it with the timeline, and then load it into the score using
```
S.load()
```
and layer sound effects over it.
For silent videos, skip this step.

Since you cannot hear the audio, run

audio.mjs check

after every build and inspect the measurements and plots. When

DROPS

is defined in

timeline.js

, it also measures the dip during the half-beat before each downbeat and the rise on the downbeat, issuing a WARN when there is no breathing room.

Step 6: Acceptance

Technical checks: These are program-determined, and a failure means the video cannot be delivered.

bash

node <skill>/scripts/inspect.mjs qa <slug>/out/final.mp4 --out <slug>/qa/final \
  --expect-size 1920x1080 --expect-fps 30 --expect-duration 16 --audio required   # Use --audio none for silent videos; add --loop for looping videos

It checks whether the file can be decoded, plus its dimensions, frame rate, duration, frame count, audio track, black frames, loudness, true peak, and loop seam when needed. If any item is marked FAIL, the exit code is 1 and it must be fixed. Specifications that were not provided are listed as NOT CHECKED and do not count as an accepted result.

build.sh

supplies the specifications automatically. The rendering tool itself also refuses to publish files with an incorrect frame count.

Review: This is for human judgment rather than program-determined acceptance. Inspect the sampled-frame sheet, phone-size frame samples, frozen segments, with intentional holds declared in

HOLDS

marked as such and all other frozen segments judged for accidental emptiness, cut points, motion and flash frames by shot, text-bounds marker images such as

qa/text-*.png

, and audio plots. Follow the review checklist in

references/review.md

, document the observations and the three most serious problems, and verify that the content matches any numbers and charts. After fixing the issues, re-render only the affected segment and then produce the complete video, recording the process in

qa/review_log.md

. If the host supports sub-agents, assign an agent that did not participate in production to review the materials and identify problems, following the “Independent Review” section of

review.md

The review conclusion is a reference for the user and cannot replace the user's own review of the video. Mark inapplicable items as Not Applicable. For example, do not force a sound-picture synchronization score onto a silent piece.

Step 7: Delivery

Tell the user:

The paths to

out/final.mp4

and

out/poster.png

. Generate the poster with

render.mjs <slug> --poster <t>

```
brief.md
```
, containing the complete structured prompt for reuse.
The technical-check results, which must all be PASS, any unresolved issues in the review log, and the rendering time.
How to rebuild the video with
```
sh build.sh
```
and how to modify only one segment.
The sources and licenses for all third-party assets, including fonts, user assets, and music. Remind the user to verify factual content again.

After delivery, spend a few minutes reviewing the work: Record what clearly improved the video in

references/field-notes.md

, together with evidence such as metrics or before-and-after comparisons. Add an entry under “Implementation Records” in

styles/INDEX.md

for every style used, and record newly discovered weaknesses in that style file. Document only reusable methods; keep user assets and private information inside the project.

Bottom Lines (Required for Every Style)

Factual accuracy: Product features, numbers, and names must come from the user or a reliable source; clearly mark anything uncertain.
Readable text: Font sizes must remain legible on a phone, and the display duration must be sufficient for reading. Text must not overflow, overlap, or be obscured; see Section 7 of craft.md.
Licensed assets: Every logo, screenshot, font, and music track must be usable, and its source must be listed at delivery.
Technical correctness: Rendering must be deterministic, all technical checks must pass, there must be no black frames, and the ending must not stop abruptly; use a held final frame or a seamless loop.
Style consistency: Follow the selected style rules from beginning to end and do not violate the brief's forbidden list.

Beyond these constraints, determine camera movement, spring use, sound-effect density, and pacing according to the style and content. See

references/styles/

and

craft.md

Tool Quick Reference (

S=<skill>/scripts

)

Purpose	Command
Install dependencies / check environment / run tests	`sh $S/setup.sh` · `node $S/check-env.mjs` · `cd $S && npm test`
Create a project	`sh $S/scaffold.sh <slug> [--audio synth\|tone\|layer\|none]`
Stills + contact sheet	`node $S/render.mjs <slug> --still 0.5,3,7.2 --sheet` · `--range 0:15:1 --sheet`
Three directions / poster	`node $S/render.mjs <slug> --directions a,b,c --at 14.5,2,0` → `qa/directions.png` · `--poster 14.5` → `out/poster.png`
Determinism	`node $S/render.mjs <slug> --determinism`
Text bounds, for review material	`node $S/render.mjs <slug> --text-check [--safe auto\|none\|T,R,B,L]` → `qa/text.json` + marker images; `build.sh` runs this automatically
Analyze a reference video	`node $S/inspect.mjs grid <ref> --strips` for cut points, beat grid, and transition frames · `heat <ref>` for per-segment motion heatmaps
Proxy / final video / segment	`--size 960x540 --out out/proxy.mp4` · final video: `sh <slug>/build.sh --subframes 2 --grain 4` , with specifications at the top of `build.sh` · `--start 6 --duration 3 --out out/seg.mp4`
Sound	`node $S/audio.mjs build <slug>/score.mjs` , or use `score.tone.js` · `samples salamander` · `beats <track> --out audio/beats.json` · `check audio/music.wav` , which reads `DROPS`
Acceptance and review material	`node $S/inspect.mjs qa out/final.mp4 --expect-…` , automatically run by `build.sh` · `sheet` · `phone` · `strip --at 4.2` · `loop` · `motion` , which reads `SHOTS` and `HOLDS` to report per-shot motion, jumps, and flash frames

Reference Files (Read as Needed)

File	When to read it
`references/formats.md`	Step 2: purpose, such as a promo, showreel, UI animation, kinetic typography, Logo, data-driven highlight, or green-screen composite
`references/styles/INDEX.md`	Step 2: catalog of 28 styles, the three-direction rule, and mixing rules; then read only the selected `styles/<slug>.md` . Use `styles/_template.md` for custom styles
`references/craft.md`	Steps 2 and 4: pacing, movement, transitions, camera, typography, color, texture, signature moments, and the list of default clichés
`references/brief-template.md`	When writing the brief
`references/stack.md`	Step 4: page contract, determinism, technology-specific pitfalls, fonts, assets, aspect ratios, and performance
`references/recipes.md`	When an established implementation pattern is useful
`references/sound.md`	Step 2, Section 2 for sound direction, and Step 5
`references/review.md`	Step 6: technical-check instructions, review checklist, independent review, common issues, and delivery checklist
`references/field-notes.md`	Step 2 when looking for prior approaches, and Step 7 for retrospective updates

motion-showreel

NPX Install

Tags

SKILL.md Content (Chinese)

Motion Showreel

Scope

Opus's Strengths and Default Pitfalls

Workflow

Step 0: Environment

Step 1: Clarify Everything in One Go

Step 2: brief.md

Step 3: Style Frames (🛑 The Only Pause)

Step 4: Production

Step 5: Sound (Optional)

Step 6: Acceptance

Step 7: Delivery

Bottom Lines (Required for Every Style)

Tool Quick Reference (
`S=<skill>/scripts`
)

Reference Files (Read as Needed)

motion-showreel

NPX Install

Tags

SKILL.md Content (Chinese)

Motion Showreel

Scope

Opus's Strengths and Default Pitfalls

Workflow

Step 0: Environment

Step 1: Clarify Everything in One Go

Step 2: brief.md

Step 3: Style Frames (🛑 The Only Pause)

Step 4: Production

Step 5: Sound (Optional)

Step 6: Acceptance

Step 7: Delivery

Bottom Lines (Required for Every Style)

Tool Quick Reference (S=<skill>/scripts)

Reference Files (Read as Needed)

Tool Quick Reference (
`S=<skill>/scripts`
)