mg-styles-15: 15 Motion-Design Films Written as Code by Claude Opus 5.5

A repo of fifteen ten-second motion-design films, each written as code by Claude Opus 5.5 from a single prompt, is trending on GitHub with about 1,300 stars. mg-styles-15 publishes the films, but the real payload is the rest: the prompts, the source for every film, the renderer, and a review rubric. In its words: "Fifteen styles, one 10-second film each, all made by Claude Opus 5.5 writing code."

The result is a reusable recipe for turning a coding model into a motion-graphics studio, with honest notes on what does and does not reproduce. This post covers what is in the repo, how to use it, and where it fits next to other code-first video work we have covered.

Quick reference

What is in the repo?

Per the README, the repo contains:

• videos/: the 15 finished films.
• prompts/: one full prompt per style.
• demos/<name>/: each film's source, soundtrack script and timing file.
• harness/render.mjs: renders frames in headless Chrome and muxes video and audio with ffmpeg.
• lib/audio/: the sound toolkit and 103 instrument samples.
• rubric.md and template.md: a review prompt, and a template for writing new styles.
• A showcase site with each film, described there as one prompt per film, everything generated by code.

The showcase page names demo folders such as 01-flat-vector and 04-3d-render, which hints at the range: flat vector through to full 3D.

An easing curve, representing code-driven motion design in mg-styles-15

How does a film become code?

The architecture is the interesting part, and it is simple. Each film is a web page that can draw any frame for a given time. A render script steps through time, captures each frame in headless Chrome, and ffmpeg combines the frames with an audio track. The audio is synthesized in Python, not recorded or generated by an audio model.

Because the film is a pure function of time, the model only has to write ordinary front-end code: SVG for flat vector shapes, Canvas for particles and 2D effects, WebGL and Three.js for 3D, and Blender for the one film that needs a full 3D render. Anything a model can code, it can animate. That is the same insight behind Lemo-Opuscar, the Claude Code skill that makes short films with code instead of a video model, which covers 43 styles; mg-styles-15 is the smaller set, with every prompt and source published.

How do I reuse the prompts?

The README's recipe:

1. Open an AI coding assistant in an empty folder.
2. Paste a prompt from prompts/ for the style you want.
3. To make it your own, replace the "Creative seed" story and branding, and keep the "Signature features", which define the style.

To render the shipped sources instead, install Node.js 22.12+, Chrome, ffmpeg and Python 3.11+, run npm install and pip install -r requirements.txt, then:

node harness/render.mjs demos/01-flat-vector

Blender is needed only for the 3D film. The rubric.md file is a review prompt you can hand to a model to critique a result, and template.md shows how to write a new style in the same format. If you want to wrap a prompt as a reusable command, agent skills are the standard container.

Why Opus 5.5, and what does it say about the model?

The README credits Claude Opus 5.5 for all fifteen. For context on the model, see our Opus 5.5 versus Sonnet 5.5 comparison and the Sonnet 5.5 building guide; for other things people made with it, the Opus 5.5 community showcase. The films are an informal demonstration of long-horizon code generation: a single prompt has to produce layout, timing, easing, shaders and a soundtrack that stay coherent for ten seconds. The README reports self-scored AI-jury ratings of 7.57 to 8.21 out of 10 and says each film went through two rounds of revision with a second AI reviewing against rubric.md, so the finished films are not literally untouched first outputs. It reports no token cost, and the scores are the author's own, so read the films as a showcase, not as a measurement.

What does not reproduce?

This is where the repo is most useful, because it is blunt about limits:

• Different film every time. In the README's words, "The same prompt makes a different film every time." Prompts define a style, not a fixed output.
• Audio only partly matches. Soundtracks are deterministic in the same environment, but with the pinned requirements only 4 of the 15 match the published audio exactly.
• Fonts are missing. Font files are not included, so without them "the browser falls back to system fonts, and the lettering will differ from the films."
• It is heavy. The showcase site is about 575 MB, mostly video.
• Third-party licenses differ. The MIT license covers the author's code, prompts, docs and films, but fonts, samples and other third-party files carry their own licenses (such as CC0, OFL and BSD-3-Clause).

How does this compare with AI video models?

Code-first films trade photorealism for control. A diffusion video model can show a person or a landscape; this approach cannot. In exchange you get editable text, exact timing, resolution independence, a deterministic structure you can version in git, and no per-second generation fee. For explainers, product launches, lyric videos and kinetic typography, that trade is often the right one. For realistic footage it is not.

Related code-first tools on explainx.ai include Claude's animated dashboards and explainers, which also lean on generated code to produce motion.

A practical workflow for your own film

The README gives the ingredients; this is explainx.ai's suggested way to combine them, not an official procedure.

1. Pick the style closest to your brief and read its prompt end to end. The prompt is long because it encodes the style: palette, motion rules, timing, and the soundtrack approach.
2. Render the shipped source first. If node harness/render.mjs works on the original demo, your Node, Chrome and ffmpeg setup is good, and any later failure is in the new code, not the toolchain.
3. Swap only the Creative seed. Change the story, the words on screen and the branding. Leave the Signature features alone, since they are what makes the style recognizable.
4. Generate several takes. Because the same prompt produces a different film each time, treat each run as a draft. Keep the best one and commit its source.
5. Review with the rubric. Hand rubric.md and your result to a model and ask for a critique, then feed the notes back as a revision prompt.
6. Install the fonts the source names, or the lettering will not match what you saw in the preview.
7. Check the audio by ear. Only 4 of 15 shipped soundtracks reproduce exactly under the pinned requirements, so expect small differences between machines.

The advantage of this loop is that every step is a text file under version control: the prompt, the source, the audio script and the timing file. When a client wants a change to one beat, you edit a number, not a timeline in an editor.

What are people asking?

Can I sell videos made from these prompts? The README says the code, prompts, docs and films are MIT-licensed, which permits commercial use with attribution, but check third-party font and sample licenses separately.

Do I need Claude specifically? The prompts are pasted into "an AI coding assistant". The films were made with Opus 5.5; other models will give different results, and none are reported.

Is ten seconds a limit? It is the format of this set. The renderer steps through frames, so nothing in the architecture described in the README forces ten seconds, but longer films would need more careful prompts and cost more to render.

What is claimed and what is verified?

The repo is a showcase by an individual developer, and a few points are worth separating. The claim that Claude Opus 5.5 wrote every film from one prompt each is the author's statement in the README; the README also says the originals took several iteration rounds, and the repo does not publish transcripts, so we cannot verify how many runs were discarded. What you can verify yourself is the structure: the prompts and sources are public, the renderer is a short script, and you can run both on your own machine. The README's own admission that only 4 of 15 soundtracks match exactly is a useful honesty signal, because it tells you the published films are one sample from a random process, not a guaranteed output.

Should you try it?

Yes if you make short motion pieces and want a starting point with documented prompts. Start with one style, render the shipped source to confirm your toolchain, then paste the prompt and compare. Expect to iterate: regenerate until you get a film you like, and keep the winner's source in version control, since you cannot regenerate it exactly.

Details reflect the repo README and showcase page as of October 20, 2026. Star counts and requirements change; check the repo.

Related reading

• Lemo-Opuscar: short films with code, not a video model
• Claude Opus 5.5 community showcase
• Claude Opus 5.5 vs Sonnet 5.5
• Claude Sonnet 5.5 building guide
• What are agent skills?
• Claude animated dashboards and explainers