animate
Skill0 starsChanged 14 days agoMITView on GitHub
Make a short procedural animation in any style — an explainer, a history, a little story — as a single-file canvas video with a synthesized score, rendered to MP4. Ships with styles (cut paper, crosshatch ink, riso print, sketchbook, manim-style math, pixel art, isometric line art) and makes new ones from the user's references. Walks the user through intake, then three check-ins (story, look, storyboard) before animating, and proves the result with measured review checks. Use when the user asks for an animated video, short, explainer or reel made in code, or wants a look matched from references.
- Installs packages
110 other projects use a version of this.
Adopted by
Most recently taken up by
- 1-Pankaj/AutonomousMarketingtheir own version, first seen Nov 8, 2026
- Tresnanda/kyberntheir own version, first seen Nov 8, 2026
- yancacchione/claude-skillstheir own version, first seen Nov 8, 2026
- illodev/drawn-by-codetheir own version, first seen Nov 4, 2026
- leepokai/Codynctheir own version, first seen Nov 4, 2026
- theexperiencecompany/gaiatheir own version, first seen Nov 3, 2026
Used with
Projects with it also use bolder, arrange and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
HK-hubSkillbolder
Amplify safe or boring designs to make them more visually interesting and stimulating. Increases impact while maintaining usability. Use when the user says the design looks bland, generic, too safe, lacks personality, or wants more visual impact and character.
Also in 29 projects that use this
HK-hubSkillarrange
Improve layout, spacing, and visual rhythm. Fixes monotonous grids, inconsistent spacing, and weak visual hierarchy. Use when the user mentions layout feeling off, spacing issues, visual hierarchy, crowded UI, alignment problems, or wanting better composition.
Also in 14 projects that use this
sanmidableSkillanimate-expo
Also in 22 projects that use this
swyxioSkillmobile-native
Apply swyx's native mobile UX preferences when designing or critiquing iPhone/iPad flows, adapting tablet layouts, choosing communication-app notification behavior, or opening notifications/deep links/widgets/shortcuts before local content is ready. Also use for iOS/iPadOS generated build configuration, signing/install/launch problems, and device playtesting. Keep existing native or cross-platform stacks; excludes browser-only responsive work and backend-only changes without native UX or delivery implications.
Also in 18 projects that use this
sanmidableSkillwrite-swift
Also in 24 projects that use this
zwy123zwySkillnormalize
将用户随意输入的提示词规范化为结构清晰、便于大模型执行的标准化提示词。适用于需要整理、统一提示词格式时调用。
Also in 19 projects that use this
- +5 more from HK-hub
- +1 more from sanmidable
Other versions110 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 110
- emilkowalski/skill★ 55ksame name
- emilkowalski/skills★ 55ksame name
- spree/spree★ 16ksame name
- usekaneo/kaneo★ 9.7ksame name
- ArcReel/ArcReel★ 6.3ksame name
- leepokai/Codync★ 2ksame name
- owid/owid-grapher★ 1.6ksame name
- Spikerko/spicy-lyrics★ 700same name
- talesofai/cohub★ 585same name
- with-pebbly/aseprite-ai-artist★ 473same name
100 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository45 other files it gives its agents.
- AGENTS.mdAGENTS.md
- skills/smokekit-ai-workflow-orchestration/templates/CLAUDE.mdCLAUDE.md
- afficheuxSkill
- motion-designSkill
- review-loopSkill
- claude-motionSkill
- sound-designSkill
- web-simsSkill
- collectSkill
- explainer-storyboardSkill
- explainrooSkill
- fixitSkill
- herdr-teamSkill
- merge-gateSkill
- motion-designSkill
- motion-graphicsSkill
- animated-chartSkill
- apple-launch-filmSkill
- brand-intakeSkill
- launch-videoSkill
- loop-coverSkill
- milestone-revealSkill
- model-showdownSkill
- motion-brief-writerSkill
- motion-effectsSkill
- motion-prompt-writerSkill
- newsletter-promoSkill
- reel-exportSkill
- reference-to-motionSkill
- motion-graphics-skillsSkill
- title-sequence-3dSkill
- vox-explainerSkill
- motion-illustrateSkill
- motion-launchSkill
- motion-principlesSkill
- motion-soundSkill
- motion-webSkill
- prd-table-rondeSkill
- product-launch-motionSkill
- remotion-motion-graphicsSkill
- rush-cutSkill
- secretscanSkill
- smokekit-ai-workflow-orchestrationSkill
- uxfixSkill
- wassupSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. 0 are common, 7 are distinctive, and 8 are very specific to this project.
0
Common
Most of the 103 edited versions we read keep these.
7
Distinctive
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 13
All paths below are relative to this skill's base directory.
- Distinctive: line 22
Reference media stays local: Never commit it, copy its code, or name its artist in published output unless the user asks to credit them.
- Distinctive: line 24
Ask with options: Use AskUserQuestion with a recommended default first, so the user can answer in one click.
- Very specific: line 29
Ask the questions in intake.md — only the ones you can't infer.
- Distinctive: line 37
Ask: approve / change beats / different angle.
- Very specific: line 41
A shipped style: read its STYLE.md and demo and draw with its kit.
- Very specific: line 50
Write pieces/<name>/brief.md (spec, style, beats, bridges, sound plan, claims + sources).
- Very specific: line 53
Test tiles while building: node tools/tile.mjs pieces/<name> tile.png <frames...> — look at them.
- Very specific: line 62
After each run append to the piece's LOG.md.
- Distinctive: line 66
Ask at intake (question 3).
- Very specific: line 67
Write the script to pieces/<name>/voice/script.json: { "lead": 1.2, "tail": 1.8, "lines": [{ "id": "open", "text": "As it is spoken.", …
- Distinctive: line 72
Never fetch a voice from a site the user didn't point to, and never clone a voice without its owner's consent.
- Distinctive: line 80
Ask at intake (question 6).
- Very specific: line 81
Put it in the piece: pieces/<name>/audio/track.wav (WAV, MP3 or M4A), and in piece.json: "music": { "file": "audio/track.wav", "start": …
- Distinctive: line 89
Ask at intake (question 7) when the subject is a product.
“Common” is measured: kept by at least 6 in 10 of the 103 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Animate
You make short animated videos in code: one <canvas>, drawn and scored procedurally, deterministic frame by frame, rendered with a headless browser and ffmpeg. The story follows a grammar studied from strong short-form animation; the look is a style — a plug-in kit chosen from styles/ or made from the user's references with new-style.md.
Requirements: Node 18+, Playwright with Chromium (npm i -g playwright && npx playwright install chromium), ffmpeg on PATH. Check them first; if one is missing, tell the user the install command and stop. For a voice-over, Python with faster-whisper (pip install faster-whisper) times every word; without it the word times are estimated.
All paths below are relative to this skill's base directory. Pieces live in the user's project at pieces/<name>/ (create pieces/ if needed); styles the user makes live in <project>/styles/<name>/.
Non-negotiables
- No animating before the storyboard is approved. The check-ins exist because a wrong story or look costs a full build.
- Look at references before drawing anything — the user's, or the style's
sample.pngand demo. Then check every key frame against grammar/FRAME.md and the style's own checklist in itsSTYLE.md. - Every factual claim on screen is checked with a web search and listed with its source in the brief. Never claim "first" without a source.
- Single file, all code: one
index.html; everything is drawn and synthesized in code — no image/audio/video files, nodata:URIs, no URLs, no web fonts in the code.tools/build.mjsenforces it. Two opt-in exceptions, both the user's own: assets (screenshots and logos in<piece>/assets/, embedded by the build) and a music track (joined at export). See Assets and Music below. - Deterministic: seeded randomness only (
RNG(...)), the boil indexBfor per-step variation. NeverMath.random()or wall-clock time. - Reference media stays local. Never commit it, copy its code, or name its artist in published output unless the user asks to credit them.
- "Done" is measured:
tools/review.mjspasses and you have looked at the contact sheets. Report the numbers, not "looks good". - Ask with options. Use AskUserQuestion with a recommended default first, so the user can answer in one click.
The flow
0. Intake
Ask the questions in intake.md — only the ones you can't infer. For the look, build the gallery (node tools/gallery.mjs <out.png> [<project>/styles], ~3s), show it and ask: which of these, or show me a reference? Then study the references yourself against FRAME.md and the style's checklist.
1. Story check (text, fast)
Pick the format from grammar/FORMATS.md — the plot engine decides it (a history is a chronology joined by morphs; a mission cuts on the beat; a list is a catalogue). Read grammar/STORY.md. Web-check the facts. Then show the user:
- the one-line idea and the sayable device ("the spark gains a ray each era and ends as the answer")
- the format and why, the style, length, BPM
- a numbered beat table: time, what happens, the bridge into the next beat, the sound's role (where the silence is, where the loudest hit is)
Ask: approve / change beats / different angle. Revise until approved. This is where "I meant X, not Y" gets caught cheaply.
2. Look check (2–4 style frames)
Start the piece at pieces/<name>/: copy piece.json and src/ from the style's demo (styles/<name>/demo/) — it already speaks the style's kit and joins eras with a morph — or from templates/beat-cut/ for a piece that cuts hard on the beat (8ths, a 16th-note rush on odd frames, one era per shot, framings from cameras), or templates/piece/ for the plainest cut-paper morph. Set "style" in piece.json, then write brief.md and LOG.md fresh (the template's are placeholders).
- A shipped style: read its
STYLE.mdand demo and draw with its kit. - The user's references: follow new-style.md. Measure the references first (
tools/measure/refs.mjs); the piece's own style frames are the matched frames, so this is one check-in: the compare sheets and the frames together. Save the style folder after the piece is approved (the piece becomes its "proven on").
Draw 2–4 of the most different beats as full-size frames. Each must pass FRAME.md and the style's checklist. Render them side by side with node tools/still.mjs pieces/<name> 2.25,9.75,16.5 look.png --scale 0.5 (or tools/storyboard.mjs with TIMELINE.board set to those beats), and show the image. Ask: thumbs up per frame / change the look / try another style.
3. Storyboard check (every beat)
Draw every beat in the approved look. Fill TIMELINE.board with one key time per beat ({ t, title, sound, next }) and render the board. Ask for thumbs up/down by panel number and notes; redraw what's down; repeat. The panels are the video's own scene functions, so nothing is redrawn later.
4. Build
- Write
pieces/<name>/brief.md(spec, style, beats, bridges, sound plan, claims + sources). Keep aLOG.md. - Animate the scenes: timed actions with
TT,ev(t, d),popS(t), write-ons (see craft.md → Motion). Wire eras, cameras and bridges insrc/bridges.js(morph-joined formats) or leaveBRIDGES = []for hard cuts. node tools/build.mjs pieces/<name>→index.html(the style's kit is pulled in frompiece.json"style").- Test tiles while building:
node tools/tile.mjs pieces/<name> tile.png <frames...>— look at them; tile across every morph and cut. - Score in
src/score.js(see craft.md → Sound). node tools/export.mjs pieces/<name> --share→ frames,audio.wav, stems,renders/final.mp4,renders/share.mp4(--formats 9:16,1:1,16:9for every format;--blur 4for motion blur on 1s styles). Iterate the mix with--only-audio(re-renders the score and remuxes it, ~4× faster).node tools/review.mjs pieces/<name>→ contact sheets per shot, cut grid, morph grid, story arc, anchor, text (cut off / overlapping / under the phone UI) and sound (the loudest moment, the silence before it, LUFS). Fix until it passes, view the sheets, write a per-shot PASS table inLOG.md. Trust the text check over your eye: a cropped label looks fine on a contact sheet.
5. Deliver
Send renders/share.mp4. Say in a few lines: what it is, the checks' numbers, what the review caught and fixed, the weakest shot, and what you haven't verified (e.g. you can't listen to the score). Ask what should change: story, look, transitions, pacing, sound.
6. Learn
After each run append to the piece's LOG.md. If something new went wrong or worked, propose a one-line rule for craft.md, the style's STYLE.md or a kit change, and add it when the user agrees.
Voice-over (optional)
Ask at intake (question 3). With a voice, the voice is the clock: each beat starts ~0.3s after the previous sentence ends, and the big moments land on spoken words. The script is the storyboard: one line per beat.
- Write the script to
pieces/<name>/voice/script.json:{ "lead": 1.2, "tail": 1.8, "lines": [{ "id": "open", "text": "As it is spoken.", "after": 0.45 }, ...] }. Write numbers and names the way they should be said. Keep it ≤ 3.5 words/s; give a line a longerafterwhere the picture needs time to land (a count, a caption, the silence before the payoff). - Build before the voice exists:
node tools/voice.mjs pieces/<name> --scratchmakes a timing voice with the OS's own speech (never ship it), so the whole piece can be animated and reviewed. - The takes: one file per line, saved as
voice/<id>.mp3with"file"set on the line.- The ElevenLabs connector (if the user has it: Claude's Settings → Connectors → ElevenLabs, signed in with OAuth, no API key): find 2–3 narrators that fit with its voice search, generate one line in each (one variation each, not four), let the user pick, then generate every line once with that voice and model. The generation result gives a short-lived download link per take: save each into
voice/. It costs about one credit per character; say the total before the full run. If the connector was added during the session, its tools may only appear after the app restarts. - The user's own recording, one file per line (or cut from one take).
- Never fetch a voice from a site the user didn't point to, and never clone a voice without its owner's consent.
- The ElevenLabs connector (if the user has it: Claude's Settings → Connectors → ElevenLabs, signed in with OAuth, no API key): find 2–3 narrators that fit with its voice search, generate one line in each (one variation each, not four), let the user pick, then generate every line once with that voice and model. The generation result gives a short-lived download link per take: save each into
node tools/voice.mjs pieces/<name>→voice/voice.wav(the lines with their pauses) andvoice.json(every line's and word's start and end, heard in the audio by faster-whisper, locally). The build injects it asVOICE.- In the head:
VL(id)is a line,VW(id, word, n)when its n-thwordstarts; beats start at the previous line'st1 + 0.3;TIMELINE.narrationcomes fromVOICE.linesandDURATIONfromVOICE.duration. Cue Writes and flashes on the words that name them. Put the payoff hit in a pause before the line that names it: a hit under speech is ducked away. piece.json:"voice": { "file": "voice/voice.wav", "music": -12 }. Export mixes the voice over the score (the score atmusicdB, ducked further while the voice speaks) to −14 LUFS. Review judges the story arc and the payoff window on the score alone (renders/audio-score.wav; a voice is louder than any hit) and the voice with its NARRATION check.- Re-takes and script edits: replace a line's file (or edit its text), rerun
voice.mjs, rebuild: scenes cued fromVOICEmove with it. A changed word can orphan a cue that points at it; check those beats.
Music: the user's own track (optional)
Ask at intake (question 6). Without a track the score is composed in code on a 120 BPM grid. With one:
- Put it in the piece:
pieces/<name>/audio/track.wav(WAV, MP3 or M4A), and inpiece.json:"music": { "file": "audio/track.wav", "start": 12.0, "gain": 0, "fade": 0.5 }(start= where in the song the piece begins). node tools/beats.mjs pieces/<name>/audio/track.wav pieces/<name> --start 12 --dur <piece length>→beats.json: the tempo, the first beat, every beat and bar, the strongest hits, the loudest moment and the drops. Pass--bpm 128if the user knows the tempo; check its "other tempos" line otherwise (double / half / two-thirds time is the usual miss).- The build injects it as
BEATS; the starter head readsBPMandGRID0from it, andonBeat(t)snaps a time to the song's 8th grid. Put cuts, morphs and cues ononBeat(...). The song decides the arc: put the turn on a drop (BEATS.quiet) and the payoff on its loudest hit (BEATS.loudest,BEATS.hits), not where a composed score would have put them. - The score (
src/score.js) keeps only sound effects (to = 's'): export replaces the music bus with the track, mixes the sfx stem on top and normalises to −14 LUFS. Review's grid usesTIMELINE.gridOffset; its SOUND section says whether the loudest moment lands in the payoff act. - The browser preview still plays the composed score (no audio files in the page); the export has the track.
Assets: real screenshots and logos (optional)
Ask at intake (question 7) when the subject is a product. Then:
node tools/capture.mjs <url> pieces/<name>/assets/home.png [--selector "css"] [--full] [--dark] [--hide "css"]screenshots the user's own site (a page, a section, the logo). Ask before capturing anything they don't own. Logo files they give you go inassets/too (PNG, SVG, JPG, WEBP).tools/build.mjsembeds everything inassets/intoindex.html(the piece stays one file, and the canvas stays readable by the checks);window.renderFrameappears once the images are decoded, and every tool waits for it.- Draw them with
drawAsset('home.png', x, y, w, h, { fit: 'cover' | 'contain', r })inside the style's own framing (a torn-paper photo, an inked frame, a printed card) so they belong to the look.asset(name)returns the image. - Real product UI only: animate the real screens (crop, push in, reveal, point at them with the hero); never draw a fake screen as if it were the product. Sample brand colours from the screenshots.
Formats: one piece, several shapes (optional)
Ask at intake (question 2, multi-select). List them in piece.json "formats": ["9:16", "1:1", "16:9"] (the first is the main one). The starter's head reads ?format= and sets W, H, SAFE and CX; scenes place things with LX(fraction), LY(fraction) and size them with UNIT, and choose a different arrangement with PORTRAIT / WIDE where a shape needs it (a column of three on 9:16, a row of three on 16:9). Never crop a 9:16 render to 16:9.
node tools/export.mjs pieces/<name> --formats 9:16,1:1,16:9 --share→renders/final.mp4(main) andfinal-<w>x<h>.mp4for the others.- Review each:
node tools/review.mjs pieces/<name> --format 16:9(andtile/still/textcheck/storyboardtake--formattoo). The text check matters most here: a wide caption that fits 16:9 can run off 9:16.
Motion: springs and blur
- Springs (
kit/core.js):springMove(t0, a, b, SPRING.snappy)moves a value with a little overshoot and a settle;springTrack([[t, v], ...])follows a value through many targets without a jump. Presets:snappy(UI),smooth(cards, camera),heavy(big type, logos),playful(mascots). Closed-form, so frames stay deterministic. On-2s styles step them every 2 frames, as they should. - Motion blur:
export.mjs --blur 4averages 4 sub-frames per frame — only for styles on 1s (STYLE.ones: math, isometric); hand-drawn looks on 2s are crisp on purpose (export warns).
Parallel agents (long pieces)
A 45–60s piece has 10–15 scenes; split the drawing across agents once the storyboard is approved:
- One
src/file per section or era, owned by one agent (src/era-01.js,src/era-02.js, …). List them inpiece.json"scenes": [...]; they take the place ofsrc/scenes.jsin the build order. - The shared parts stay with you:
src/head.html(TIMELINE, eras, shots, cues),src/bridges.js, the score, and the kit. Agents read them but never edit them; if a scene needs a kit helper, they write it in their own file under a prefixed name. - Brief each agent with the approved board panel(s), the style's
STYLE.md, the era's time range and cue names, its bridge objects (what must be in frame at the boundary), and the rules: deterministic, no new globals without the era prefix, tile its frames and look at them. build.mjsjoins them; you build, tile across every boundary, and run the review.
Files
| path | what | read when |
| intake.md | the questions and defaults | step 0 |
| craft.md | the distilled rules: story, frame, motion, timing, sound, code, review | before step 1, and when building |
| grammar/FORMATS.md | 8 story formats (engine × stage × clock), invariants, which are proven | step 1 |
| grammar/STORY.md | beat-level story rules with evidence | step 1 |
| grammar/FRAME.md | what a single key frame must hold, in any style | steps 2–3 |
| styles/ | the styles: STYLE.md (rules + frame checklist), kit.js, sample.png, demo/; the STYLE hooks contract | steps 0, 2, building |
| new-style.md | making a new style from the user's references | step 2 |
kit/core.js | RNG, easing, geometry, the hand-drawn line (wobble, ink, paint, hatch, pencil, stipple, grain), cameras, time helpers | building |
kit/morph.js | the renderer: eras, push-ins, zoom bumps, shape-morph bridges, overlays — draws through the style's STYLE hooks | building |
kit/board.js | the storyboard renderer | steps 2–3 |
kit/score-*.js | synth (pluck, pad, drone, bass, sub, noiseHit, sweep, riser, chime, blip), loudness stage | scoring |
| templates/ | piece/ (an 8s cut-paper morph), beat-cut/ (a 6s hard-cut piece with a 16th rush), style/ (a blank style kit for new looks) | step 2 |
tools/ | build, tile, still, storyboard, export, review, textcheck, compare (reference vs frame), gallery, framehash (pixel-identity check), beats (a supplied track's beat map), capture (screenshots of the user's site), voice (a voice-over's lines and word times); measure/ for references (refs.mjs for stills, shotlog.py for video) | throughout |
| examples/history-of-ai/ | a full 60s worked example (cut paper) | when unsure how something fits |
Honesty about what's proven
Formats F2 (chronology / morph chain) and F4 (mission) have each produced a piece that passed every check from the card alone; F5 (fixed-hero journey) has several. The others are documented from study but unproven — say so when you pick one. Cut paper and crosshatch have carried full pieces; riso, sketchbook, math and pixel each come from one or two finished pieces plus a demo; isometric was made from references with new-style.md and so far has only its demo; a style made from new references is new ground until it has carried a piece. WebGL motion design (ray-marched 3D, motion blur, bloom) is not a shipped style yet.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

