huashu-art-motion: a skill pack that makes coding agents draw in motion

It is a skill directory, not a rendering library

The unit of distribution is a skill folder. Installation is one command:

npx skills add alchaincyf/huashu-art-motion

What lands on disk is a hierarchy an agent is meant to read before it writes anything. `SKILL.md` sits at the top and its stated job is to judge the task first, then read the matching document from a table. Under `references/` come the method documents numbered 01 to 12, the 36 style recipe cards in `references/风格配方/`, the 9 narration grammar cards, and a file of positive experience notes. Under `scripts/` come the engine, the analysis tool, the quality gate and the delivery script.

So the mechanism is instruction plus code, not a callable package. There is no importable API in the README and no versioned interface. What you adopt is a set of decisions: which style card to start from, which scene script to copy, and which gates the output has to clear. That framing matters for anyone deciding whether it fits, because there is nothing here to pin in a requirements file.

One frame first, then motion

The central method is stated as design a single frame, then make it move. The author describes rejecting a first attempt that only crossfaded between static images, because the reference piece gave each era about a second yet everything inside the frame was in continuous flow. The replacement workflow starts with `scripts/analyze/breakdown.py`, which takes a reference animation and turns it into a map of transitions, a fitted beat grid and a motion heat map per segment.

Once a style is chosen, the scene code does the drawing. The repository ships 35 scene scripts in `scripts/engine/scenes/`, sitting under 17 drawing and animation libraries in `scripts/engine/lib/` covering brushes, renderers, post effects, skeletons, camera moves, charts and typography. Characters follow a different path: the image generation model supplies the frames, and code handles compositing, frame swapping and materials. That division is the project's clearest constraint and it is stated without hedging.

The long-scroll format works the same way. Each world is a separate segment file, the protagonist walks right, and crossing a boundary swaps the painting style, with the camera pushing in only and never retreating.

Rendering a single still before committing to a film

Dependencies are uv, ffmpeg and Playwright Chromium. The README gives the one-time browser install:

uv run --with playwright playwright install chromium

Then a first render, one frame from the Van Gogh segment, to check the pipeline before anything long runs:

cd huashu-art-motion
uv run --with playwright python scripts/engine/render.py --solo 09_postimp --stills 0.3 --out 试渲

`--stills 0.3` samples stills along the segment, and `--out` names the output directory. A full segment driven by a spec file looks like this:

uv run --with playwright python scripts/engine/render.py --spec scripts/engine/examples/t3_finance_chart.json --out 财经图表.mp4

Both commands go through `uv run --with playwright`, so the Python environment is resolved at call time rather than installed by hand. Anything that reads wrong visually, a wrong brush direction or a badly framed text box, is far cheaper to catch in the still pass than in the encoded file.

The delivery gate red-lights films with no in-shot motion

Quality control is the part most worth borrowing. `qa.py` measures stability, efficiency, motion energy, flow and text framing clues, then dispatches a separate agent that has not seen the production work to watch the finished film and list problems. `film_gate.py` reads the mp4 read-only and scores it for page-flipping PPT feel and for blank stretches in the middle.

That gate has teeth. The README states that a film with almost no in-shot fast motion fails and produces no output. `deliver.py` chains the sequence: run the gate, and only if it passes copy the film and write the delivery notes. The notes are written by the script, so the stated facts in them come from code rather than from a write-up done by hand.

The framing of a numerical acceptance step followed by a fresh-eyes review is unusual for a creative tool, and it is also the main reason to take the repository seriously. Creative pipelines usually fail by shipping the worst take.

Grammar cards for narration, one of which ships no character

Nine narration grammars are documented, and eight come with a runnable demo clip, parameterised snippets and an example spec. The named set includes Kurzgesagt flat shapes without outlines, Vox collage with cut lines and highlighter marks, a whiteboard style where the pen tip reveals line art, 3Blue1Brown where one object morphs into the next, storytime reaction close-ups with comic pauses, kinetic type, a keynote style with frosted glass cards, and a finance chart grammar that draws the axis first and then the data.

The ninth is a presenter-style finance explainer, and it is the awkward one. It ships a grammar card and a full-film code snapshot, but you supply the character yourself. That is an honest gap rather than a defect, and it is worth knowing before you plan a series around it.

The repo also flags a misuse directly: the 35 style overview images reuse one composition across every style, which suits an art history speedrun where the style changes and the scene does not. Using those compositions for new subject matter is called out as wrong, because the composition has to be redesigned per subject.

Licensing is MIT except for three named carve-outs

Code and documentation are MIT. Three exceptions are spelled out. `reference_films/spacex/spacex_wb/assets/strokes.js` keeps the Arphic Public License that shipped with the file, fonts under `scripts/engine/lib/fonts/` stay under their own OFL licences, and the cartoon character and character frames under `scripts/engine/demos/_shared/hero/` and the long scroll demo are reserved by the author. Font licensing is listed in `scripts/engine/lib/fonts/LICENSES.md`, and the fonts themselves are SIL OFL 1.1.

Attribution is handled carefully too. The project credits a 15 second art history speedrun as its starting point but states that the repository contains no frames, screenshots or audio from that film, and that only the analysis method was kept.

On maintenance, the last push was on 2026-10-14 and release v1.1.0 landed the same day, following v1.0.0 on 2026-10-06. Two releases in ten days is a young project with a fast churn rate, so the 36 and 35 counts can move, and anyone automating against the directory layout should expect renames.

Editorial conclusion

Adopt huashu-art-motion if you produce narrated explainer videos or style reels and you want the motion generated by code rather than by hand keyframing, since the engine, scene scripts and delivery gate arrive as one bundle. Do not adopt it expecting a reusable library or a headless pipeline: characters still need an image generation model, and the repo says so plainly. Before the first render, check that uv, ffmpeg and Playwright Chromium are present, then render a single still with `uv run --with playwright python scripts/engine/render.py --solo 09_postimp --stills 0.3 --out 试渲` to see whether the Van Gogh recipe suits your footage.

Frequently asked questions

Official sources

1. alchaincyf/huashu-art-motion on GitHub
2. Issues
3. License: MIT
4. README
5. Releases