# lemomo-ai/lemo-opuscar: 43 film styles where the demo is code, not a video model > A 1,281-star repository of Claude Code skills that produces short films by having an agent render every frame on canvas or WebGL. Its GitHub releases are not versions at all, they are CDN channels for the finished films. **lemomo-ai/lemo-opuscar** — Claude Code skill for making short films with no video model: 43 film styles, each a style prompt plus a demo film made entirely in code by Claude Opus 5.5 (including OPUSCAR 98). By Lemomo. - Repository: https://github.com/lemomo-ai/lemo-opuscar - Website: https://lemomo-ai.github.io/lemo-opuscar/ - Stars: 1,890 · Forks: 205 - Language: JavaScript - License: MIT - Published: 2026-10-08 · Updated: 2026-10-08 · Language: en - Canonical page: https://hysenlabs.com/projects/lemomo-ai-lemo-opuscar ## Every reference film is code, and that is the argument The repository claims 43 film styles, and each one ships a short demo film made entirely in code. The README is explicit about what that means: every film was directed, drawn, scored and mixed by an AI agent writing code, using canvas and WebGL pages rendered frame by frame, original music from free sample libraries, and text-to-speech narration. No video generation, no stock footage. That choice does the heavy lifting. A prompt library for video models can only tell you what to ask for, and the output varies with the model version you happen to be on. A code-based reference film is a pipeline you can read. If you want to know how the watercolor style handles a wide shot, the answer is in the frames of a film that was actually produced that way, produced by the same agent the repository asks you to use. The author is also unusually direct about what the collection is not. A blockquote says this is not an awesome list, that every film was made by the author with one specific model, and that the styles are tuned for it so other models may not reproduce them. That caveat does more work than a benchmark would. It tells you the styles are not portable prompt text, they are a set of habits encoded for one agent, which is a much more useful thing to know before you spend an hour of tokens on a disappointing result. The headline demo makes the ambition concrete. OPUSCAR 98 is a 6 minute 31 second film in which a character walks through all 98 Best Picture winners, each redrawn in a style chosen to suit the film it comes from, spanning winners from 1927 through 2025. Every frame, note and cut was written in code. That is either the most useful single artefact in the repository or a curiosity, depending on whether you intend to make films. ## GitHub releases used as three asset channels, not a version history The releases in this repository are the most unusual thing about it. There are three tags and they are called `web`, `films` and `assets`. Two of them are named for what they carry rather than for a version: web cuts at 720p copied into the gallery, films streamed by the gallery, and assets fetched by a script under `tools/`. All three were published on the same day within about ten minutes of each other, and every release body reads the same single line, that it is a rolling release updated by a publish script. This is a CDN built out of GitHub's release attachments, and it is a deliberate reuse. The gallery site streams the films, the asset script fetches support files, and the demo download link points at a path under the films tag. Because the releases are rolling, the attachment at any given URL is overwritten in place. That is exactly what you want for a continuously updated gallery and exactly what you do not want if you were trying to pin a version, because there is no version to pin. The consequence for a user is simple and worth stating: there is no changelog, no upgrade path and no compatibility contract available from the releases. The actual versioning lives elsewhere, in a package manifest carrying version `0.1.0` and marked private, and in the plugin marketplace you install from. If you want to know what changed, your options are the commit history and the changelog file, not the release list. This is also why the repository is not published to a package registry even though it has a manifest with dependencies. The manifest declares `playwright-core` and `three` as dependencies, which is what a headless browser renderer and a WebGL scene would need, but with the package marked private the npm path is closed. The installation story runs entirely through the agent plugin marketplace. ## Two ways in, both ending in a folder of code Installation offers a skill route and a clone route. The recommended one adds the repository as a plugin marketplace and installs the skill from it: ```sh claude plugin marketplace add lemomo-ai/lemo-opuscar claude plugin install lemo-opuscar@lemolab ``` Note that the marketplace is the repository owner and name, while the plugin package name inside it carries a different suffix. That is normal for a marketplace that hosts more than one plugin, and `MAINTAINING.md` in the tree is presumably where that structure is documented. On first use the skill downloads the guides, tools and style prompts to a shared directory in the user's home folder, shared by all films, while each film's project goes into whatever folder you started from. For agents other than Claude Code the instructions are to copy the skill directory into their own skills folder. The clone route is three commands: ```sh git clone https://github.com/lemomo-ai/lemo-opuscar.git cd lemo-opuscar claude ``` Here films go into a `films/` folder inside the repository instead. The structural difference is where you write your work: with the skill, your film lives beside whatever project you were in; with the clone, it lives inside a checkout of the styles repository, which means your work is in a git repository that is not yours to commit to. Once installed, the interaction is one sentence. You name a style, in English or Chinese, and describe the film you want, and the agent asks a small number of questions up front about anything it cannot decide, about whether you have your own voice or music, and about whether you want to see a storyboard before it renders. The style index in the styles directory lists all of them. The storyboard option is worth turning on for a first run, since it stops the pipeline once, in the real style, before committing to a full render. ## Three guide files, and a rendering stack split across two runtimes The agent is handed three documents, and the division of labour between them is the actual design of the project. `DIRECTOR.md` covers how to direct, namely story, sound, rhythm, camera, performance and self-checks. `TECHNIQUE.md` covers how to build, namely frame-by-frame rendering, voice, music and mixing. A per-style file covers what that style looks and sounds like, with the story left to you. Separating directing from technique is what lets 43 styles share one pipeline. The style file is a description of a look, not a program, and the technique document is the program that renders it. That is also why the styles can be tuned for a specific model and still be readable by a person. The runtime requirements are heavier than the README's framing suggests, because rendering happens in a browser and audio is assembled in Python. Node 20 or newer is required, plus ffmpeg and Python 3.11 or newer, or the uv tool to provision Python. The Python dependency file is organised in tiers, with a core tier covering sound effects, the mix, subtitles and contact sheets, installed through a setup script inside the skill directory: ``` numpy scipy soundfile soxr pillow ``` Three more requirement files exist for the voice tier, the music tier and maintainer tooling. The split means a film that only needs the core pipeline installs five packages, while narration and music generation are opt-in. That matters because text-to-speech is the most likely place a local setup fails, and deferring it means a film with your own voice material is not blocked on it. Output defaults to 1920 by 1080 at 24 frames per second, with other sizes available on request. Changing that changes render time substantially, since the frame-by-frame approach pays cost per frame, so a smaller first render is a reasonable way to find out whether the pipeline works on your machine before committing to full resolution. ## Cost, licence metadata, and an unusually clean issue tracker The README states the cost plainly: a film takes an agent about 30 to 60 minutes and a fair amount of tokens. For a 6 minute 31 second film covering 98 distinct visual treatments, that is a good ratio, and for a 45 second film in one style it is probably a generous one. Either way this is not a tool you run in a loop over a hundred ideas, and the sensible first move is the storyboard option. The licence metadata has a small contradiction. The repository metadata reports no recognised licence, while the tree contains a `LICENSE` file and the package manifest declares MIT. Both can hold if the licence file is in a format GitHub does not auto-detect, and the substantive position is that MIT is intended. But as with any of these repositories, the version a tool reports is the one an automated check will read, so if licence clarity matters to you, that mismatch is worth raising rather than assuming. The other metadata oddity is the open issue count: zero, against 1,281 stars and 147 forks. Very few active projects have a clean tracker, and it is a signal either of very recent attention or of issues being handled elsewhere, such as the linked social account. The repository is not archived and was last pushed on 2026-10-05, so it is being worked on. The topics are more revealing than the description. Alongside the expected entries for agents, animation and filmmaking, they include canvas, webgl, ffmpeg and threejs, plus text-to-speech and creative-coding. Those seven are the actual technology list. There is no video generation topic, and there is not meant to be one. ## What the repository does not tell you Two gaps are worth knowing about. The first is model specificity. The README says the styles are tuned for one model and other models may not reproduce them, but it does not say what specifically depends on the model. If you are running a different agent, you are in undocumented territory, and the style files may contain instructions that assume a particular tool-calling behaviour or a particular amount of patience. The second is the audio side. Music comes from free sample libraries and narration from text to speech, and the requirements files show that both are separate tiers, but the README does not say which sample libraries, whether the licences are checked, or what the quality ceiling looks like. For a project whose claim is that the film is directed, drawn, scored and mixed by the agent, the score is the part with the least evidence in the documentation. On the visual side the evidence is stronger by construction. Each style has a demo film, and the repository shows a frame from each in a gallery table with a title and a one-line premise, which means you can judge a style from a single frame before spending an hour producing one. That is the right way to choose, and it is the argument for a demo-per-style repository over a prompt list: you can see the thing before you make it. The honest summary is that this is a well-evidenced portfolio with a working toolkit attached. The films prove the styles, the guide documents make the pipeline reproducible, and the plugin packaging makes it a one-command install for the agent it targets. Whether 43 styles is the right number for your taste is a question the gallery answers faster than any description can. ## Conclusion The interesting claim in this repository is that the reference film for each style is itself the proof, made by rendering frames in code with the same agent you would use to make your own. If you want the visual language of hand-painted watercolour or Chinese ink wash, you are copying a pipeline rather than a prompt, which is a more reliable thing to copy. The costs are real: Node 20, ffmpeg, Python 3.11 and roughly half an hour to an hour of agent time per film. The styles are tuned for one model and the README says plainly that other models may not reproduce them. Read `DIRECTOR.md` and `TECHNIQUE.md` before your first run, look at one `styles/