ohad6k/emulo/video

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.

1. Store the resolved absolute path as EMULO_PY, then run

python "$EMULO_PY" plugin profile-path --domain video.

1. If it exits nonzero, give its exact recovery instruction and stop loading

personal context. Never substitute a generic creative persona.

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

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

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.

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.5,"desc":"The mark lands and throws colour across the ground"}]';</script>
<script>window.OM_PLAYBACK = '{"mode":"loop"}';</script>

Easing, the complete list. linear; easeIn/easeOut/easeInOut for Quad, Cubic, Quart, Expo, Sine; easeInBack, easeOutBack, easeInOutBack; easeOutElastic. Back and elastic overshoot, so they belong nowhere near a logo or an official brand file.

Render from `T` only. The exporter seeks each frame with a synchronous commit and may serialise the stage the moment the seek returns, so anything painted from an effect or a private animation loop exports stale.

Captions only when asked. Render <Captions> only when the brief or the person's video profile asks for burned-in captions. Many people add their own afterwards, and a burned caption ruins that. Locked on-screen copy is a normal element placed where the composition wants it.

Set `bg` to the film's ground, never the #0b0b0e default, and never #000000. A designed world needs somewhere for light to fall off to.

Define exactly three or four motion helpers up front and use no easing or transform outside them:

MOTION.slam    Easing.easeOutExpo     arrivals and impacts
MOTION.snap    Easing.easeOutBack     chips landing, overshoot capped at 6%
MOTION.drive   Easing.easeInOutQuart  travel, light, drift
MOTION.settle  Easing.easeOutQuart    the final resolve

3. Assign the references. Never average them.

Every reference gets one job and an explicit do-not-copy list. Without the line "do not average the references" the model blends the styles into mush.

Write it into the prompt in this shape:

Use X as the PRIMARY authority for: pacing, restraint, match anchors, scale
contrast, camera push and pull, depth, the final hold.
Use Y only for: monochrome identity, typography, exact logo, clarity.
 
Do not copy X's design. Do not introduce X's colour. Do not average the
references.

If the person has several finished films on the same engine, read at least three and ask what is the same in all of them: how a scene list is declared, where the transformation chain is expressed, how an entrance is timed against the thing it hits, how the last three seconds are built. The constants are the workflow. Anything present in only one is that film's costume.

Build in stages, and gate between them. Build the first five to eight seconds. Render. Look at a contact sheet. Only then continue. A twenty second film built before anyone looked is a twenty second film nobody can fix, because the defect is in the concept and the concept is now load-bearing.

4. Build the kit before you write the prompt

A long, detailed prompt with no real assets still comes back as grey rectangles standing in for text and a hand-drawn shape in place of the real mark, because placeholders are the only thing a model can draw with nothing real to place.

Claude Code builds the kit. Claude Design animates it. That split is the pipeline.

1. Measure the reference at 1:1, one file, never a contact sheet. Write down

beats, ground colour, mean luminance, mean saturation, and what physically occupies the frame.

1. Brand intake. Official marks usually live on the brand's own guidelines

or press page, mixed in with their "don't do this" examples. Render a light and dark contact sheet and look before naming anything.

1. Rebuild the product UI as live DOM carrying real strings, then shoot it

at 3x to 5x into flat plates with a headless browser. Interfaces are rebuilt. World art is rendered and composited. Nothing is faked.

1. Cut parts, not screens. A whole screen is a slab, and a slab cannot be

animated, only slid. Ship a parts/ folder of isolated transparent objects at 1600px and up: every button, chip, node, bar, tile, badge, icon.

1. Split the mark into its own layers. An official SVG splits into layers

that stack back pixel perfect. Verify it: stacked against the original, the maximum difference on any pixel should be about 1 of 255, which is antialiasing. Then the film assembles the mark instead of cutting to it.

1. Optimise. Keep each file small (a few hundred KB) and the whole kit a few

MB, so it survives being carried into a Claude Design project.

1. Open every file and log its defects in `KIT.md`. Clipped buttons, missing

alpha, wrong aspect, white emblems that vanish on a white card. Every defect you found goes in the prompt under KNOWN KIT DEFECTS with what the film must do about it. If you found none, say you opened every file and found none.

Aspect is a real defect class. Rendering 1200x800 chips into a 224x160 box stretches every one horizontally by 7%, which is subtle enough to survive review and wrong in every frame.

Published artifacts may run under a strict CSP that blocks external hosts, so nothing in a kit should point at a CDN. Everything is a project file or a data URI.

5. Write OM_SCENES first

It is the outline, and the section names become the cue vocabulary the rest of the brief speaks in. Six sections is a good film. Ten is a slideshow.

Each desc is one sentence naming a physical event, not a mood. "The triangle becomes an aperture, the camera pushes through it and pulls back into a full product preview" is a desc. "A sense of speed and possibility" is not.

6. The transformation chain, as match anchors

Name the one object that carries the film and forbid breaking it.

Every scene inherits one visible object, shape, line or motion vector from the

previous scene. Never: scene fades out, empty background, next scene fades in.

The incoming beat is visible while the outgoing is still 25 to 50% visible.

For example, one coloured circle that is the brand mark, then a lesson node, then the thing every name collapses into, then the mark again. Or one track title printed on every product surface, so the same song moves from bar to desktop to phone.