/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: where the person's own mined rules disagree with a default in this skill, theirs win. 5. If the project has its own video docs or router, read them first and follow them for anything they cover.

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 in the project, in a folder named for the brand or the film, in this shape:

| # | 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 five 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 a 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 large plates at the film's aspect ratio for the ground. A whole screen dropped in is a slab and reads as broken. Films built this way fail on missing assets far more often than on prompt length.

**Put the instruction in the filename.** `REF_03_object-becomes-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

2. The engine

`animations-v3.jsx` is the Claude Design composition runtime. Read its header once, then work from this table.

**Never edit `animations-v3.jsx`.** Its own header says re-running `copy_starter_component` overwrites it, so every change made there is lost 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 makes zero cuts and one object transforming across the film the engine's 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 literals in plain inline `<script>` tags of the main document, not `type="text/babel"`, passed through untouched. Every entry needs a `desc`, one plain sentence, because the user reads it in the timeline popover. Never hand-set `nat`.

<script>window.OM_SCENES = '[{"name":"Strike","dur":2