/video

name: video
description: Use when a brief has to become a film. Turns a one line ask into a Claude Design prompt written in the animations-v3 engine's own language, plus the built piece.jsx and a contact sheet to look at before anyone renders. Covers reference roles, the kit, the storyboard gate, the motion floor, and the verification commands. Do not use for backend work, UI design, or marketing copy alone.

Emulo video

You take a brief and hand back a film. Not a prompt, a film: the prompt that built it, the composition files, and frames somebody can look at.

0. Load the profile before you write a word

1. Locate `emulo.py` two directories above this skill; fall back to `./emulo.py` only for a direct repo checkout. 2. Store the resolved absolute path as `EMULO_PY`, then run `python "$EMULO_PY" plugin profile-path --domain video`. 3. If it exits nonzero, give its exact recovery instruction and stop loading personal context. Never substitute a generic creative persona. 4. Read every returned path completely. First is the core working profile, second is the video profile. Both outrank anything below. 5. If the repo has `videos/README.md`, it routes short-form work. **This skill owns long-form and commercial film only.** A vertical Reel that is a designed film, not a screen recording, is this skill.

1. What you hand back

**A folder the person can upload to Claude Design and get a film.** That is the deliverable. Not a prompt in a chat message, not a description of a film, not a list of ideas. A folder.

Build it at `videos/_kits/<brand>/` in this exact shape, because the shape is what makes it work:

| # | Artefact | Why it is there | |---|---|---| | 1 | `PROMPT.md` | the brief. One page, in the engine's language | | 2 | `START-HERE.md` | **the upload order.** Which files, in which order, in one message. Without it the person guesses and the guess is wrong | | 3 | `ATTACH/` | every asset the film needs, including `animations-v3.jsx` itself | | 4 | `frames/` | reference stills whose **filenames carry the instruction** | | 5 | `KIT.md` | the manifest: every file, its pixel size, its known defects |

Optionally, and only after the four above are finished: `build/piece.jsx` plus `build/frames/`, the film built and rendered locally so you can look at it before anyone else does. That is verification, not the deliverable. A kit with no local build still ships. A local build with no kit does not.

The three things that decide whether the folder works

**Ship the engine inside `ATTACH/`.** `animations-v3.jsx` goes in the folder with the assets. Claude Design needs the runtime it is being asked to write against. Leaving it out is the most common way a good prompt produces a bad film.

**Isolated parts, never a screenshot of a whole screen.** One object per file, transparent, 1600px minimum on the long edge, plus 4K plates at the film's aspect ratio. A whole screen dropped in is a slab and reads as broken. Claude Design films fail on missing assets, never on prompt length.

**Put the instruction in the filename.** `REF-VERCEL_03_object-became-the-mark.png` teaches; `ref3.png` does not. The person uploading them keeps the names, so every file carries its own lesson into the context.

Name what is missing. Never invent a substitute.

If an asset does not exist, say so in `PROMPT.md` under its own heading, and say what to do instead. A brief that admits two missing assets is usable. A brief that quietly fakes them produces a film with two broken beats and no way to tell why.

Every prompt contains, in this order and by name

1. **the brief in the engine's language**: `OM_SCENES`, `CUES`, named `Easing` 2. **the transformation chain, as match anchors**: what becomes what 3. **the asset list**, with real filenames, so no beat is blocked on a missing part 4. **the failure conditions for this specific film**, not generic ones 5. **the verification commands**, so the claim "it works" has an output behind it

A worked example of the whole shape is `videos/_kits/claude/`: brief, upload order, 31 assets with the official mark split into stackable layers, twelve instruction-named frames, and two missing assets named rather than faked.

2. The engine

`animations-v3.jsx` is the Claude Design runtime. Read `videos/_kits/_engine/README.md` once, then work from this table.

**Never edit `animations-v3.jsx`.** Its own header says re-running `copy_starter_component` overwrites it. Every improvement made there is destroyed on the next host copy. The leverage is in the brief.

| Use | Never use | |---|---| | `Easing.easeOutExpo` and the named curves | `cubic-bezier(...)`, any CSS string | | `OM_SCENES` named sections with `dur` | absolute frame numbers as the structure | | `CUES.SectionName` to key choreography | wall clock, `setTimeout`, `requestAnimationFrame` | | `animate({from, to, start, end, ease})(T)` | `useEffect` painting anything visible | | `interpolate([...], [...], ease)(T)` | CSS keyframes running on their own | | `<Shot from to>` for a hard cut | conditional mounting per section | | one `<CompositionStage>` as the only exportable root | the exportable attribute anywhere else |

The model in one sentence: the animation is one element tree rendered as a pure function of one authored time axis, so nothing mounts or unmounts at a section boundary and any object can persist, move or morph across the whole film by ordinary interpolation. That is why this engine suits the work. Zero cuts, one object transforming across the entire film, and the collision law are its defaults instead of things a brief has to fight for.

<CompositionStage width={1080} height={1920} bg="#161309"
                  scenes={window.OM_SCENES} playback={window.OM_PLAYBACK}>
  <Piece />          // ONE component, the whole film
</CompositionStage>

useComposition() -> { T, CUES, time, duration, authoredTotal, playing }

`OM_SCENES` and `OM_PLAYBACK` are JSON string