bang-motion ships one index.html and asks an agent to check its own work

The deliverable is one HTML file, not a video file

Every project this skill produces ends the same way: a single index.html. You double-click it and it plays. It autoplays and loops on its own, a query flag adds a scrub bar for stepping through the timeline, and there is an optional frame-by-frame path to an MP4 if you need a file for someone who will not open a browser.

That output contract is the whole reason the thing exists, and it is a deliberate narrowing. A motion designer working in a browser already produces HTML, CSS and SVG, so a deliverable that is a web page is not a downgrade from a professional workflow, it is the native form of it. The cost is the same one every browser-based motion tool carries: you are trusting that whoever opens the file has a browser that renders what you wrote, and you have no video editor in the loop to fall back on.

The interesting commitment is the last one. A frame-by-frame export means the animation is expected to be deterministic, which in practice means the timing has to be authored rather than emergent. If you have ever watched a generative animation drift when re-run, that export path is the constraint that keeps the project honest, because anything non-reproducible cannot be exported frame by frame at all.

Four rules an agent can check in its own code

The stated reason for the package is a complaint about default output. Ask a coding agent for a video and what you usually get back is slides: one section per idea, a title, a photo, a fade between them. The package's answer is to encode what a working motion designer insists on as rules rather than as adjectives.

Four of those rules are named directly, and each is checkable. There has to be one continuous world rather than a sequence of separate screens. The camera has to actually move. The subject has to persist. Text has to live inside the scene rather than sit on top of it. None of those are aesthetic preferences stated as feelings, which is the point: an agent can read its own output and check whether the subject persisted or whether the text was overlaid.

The distinction between a rule and an adjective is what makes this approach workable at all. A prompt asking for cinematic footage returns whatever the model thinks cinematic means, and gives the model nothing to verify. A rule that says the camera must travel through the layers rather than cut between them can be checked by reading the timing function, and failing that check is something the agent can fix before showing you anything.

Ten styles, nineteen concepts, nine render families

The variety claim is a multiplication rather than a list, and the arithmetic is given explicitly: ten style directions by nineteen opener concepts by nine render families, producing three candidates for you to pick from rather than one take-it-or-leave-it result.

The ten styles are the skin, and each is specified as a coherent set rather than a mood. Each entry names a background treatment, a typography pairing, a signature motion, and the kind of product it suits. Cinematic dark is a near-black gradient with particles and bloom applied only to objects, set in a bold clean grotesk, moving by push-through with light travelling in front of the lens. Luxury dark is black with gold, soft shadows, a tall wide-tracked serif, and slow motion with sweeping light. Brutalist mono is a hard grid in black and white, monospace against condensed, moving by hard cuts and shifting blocks with a blinking cursor.

The nineteen concepts are the structure instead, and they are chosen per product rather than per aesthetic. One continuous shot for creative tools and hardware. Pure typography for strong taglines and releases. Problem then gone for productivity tools. Before and after for editors and filters. A journey inside the interface for apps with a distinctive one. Product macro for hardware, packaging, food and fashion. Object metaphor for security, cloud and finance. A living number for milestones and performance. One feature, fully demonstrated, for apps with a single clear edge.

The look is required to come from your brand, not the starter

The second stated purpose is anti-uniformity, and the mechanism is a requirement rather than a suggestion. The style brief is required, the structure is chosen from the menu of concepts, and nothing is inherited from the starter or copied from a reference.

This is the part that separates the package from a template gallery, and it also constrains you as the user. You have to supply a brand before you get anything, which means the first run of any project begins with you writing down your palette, your type and your imagery. If you do not have a brand system yet, that step will stall, and the tool has no default to fall back on.

A required brief also changes how the style menu is read. The ten directions are not ten looks to pick from in the abstract, they are ten starting points that your brief then overrides in specific directions. Brutalist mono for a developer tool and brutalist mono for a consumer app should not produce the same file, because the brief decides whether the hard grid is on brand or a costume.

The style gallery is openly fictional

The sample gallery carries a disclosure at the top of it, and it is the kind worth reading before drawing conclusions from the samples. Every frame is a single static scene built for the documentation, with fictional brands and fictional data.

It then gets more specific about how the images were made. The portrait, the product photographs, the port photograph, the engraving, and the cartoon cutouts were produced with an image generation model. Everything else in the gallery is HTML, CSS and SVG. Real projects take their palette, type and imagery from your own brand, which the disclosure repeats at the end.

That split explains a lot about what you are looking at. The scenes are static single frames rather than playing clips, so you are judging a look and not a timing, which is exactly what a gallery of this kind can honestly offer. And the presence of generated cutouts in some styles and pure code in others tells you which styles lean on photography as a material and which are built entirely from shapes and type.

Seven deliverable types, each with a length it tends to run

The deliverable table is where the package is most concrete, and it pairs each output type with what it is for and how long it usually runs. Openers and promos cover product launches, app promos, campaign spots and teasers, running fifteen to forty seconds. Product and SaaS demos assemble a real interface on screen and follow the clicks with the camera, twenty to sixty seconds.

Kinetic typography is for lyric-style statements, event announcements and manifestos, ten to thirty seconds. Bumpers, idents and channel intros are short brand moments built to loop, three to ten seconds. Explainers come in six styles with optional voice-over sync and either a widescreen or a vertical frame, thirty to two minutes.

Two rows in that table are not browser animations at all. Video layers place your own or generated clips like footage, inside devices, inside frames, inside masks, locked to the timeline. After Effects builds put cartoon explainers inside the compositing application directly, through a bridge to a third-party MCP server. Both are honest scope expansions rather than hidden features, and both mean the one-file guarantee applies to the browser deliverables rather than to everything the skill claims.

It is a skill package, not an application

The repository is small in the way a prompt package should be: a skill definition file at the root, a folder of reference material, a folder of scripts, a documentation folder, an assets folder, a plugin manifest directory, a changelog, a licence, and two icon files. There is no build system, no runtime and no published releases.

That shape is the point. It is designed to be loaded into whichever coding agent you already use, and the file names four of them by name as supported hosts. Nothing needs to be compiled and nothing runs on its own, which also means there is no version pinning to manage beyond the agent, and no upgrade path of your own to think about.

The two icon files are a small tell about who this is for. A raster icon and a vector icon at the root of a package whose output is a web page is someone who has thought about how the skill appears in a marketplace or a plugin list, not just about what it generates. The absent releases are a related tell: this is a thing you take from the repository rather than a version you pin.

Editorial conclusion

The idea worth carrying out of this one is the refusal to inherit a look. Most generated motion starts from someone else's starter and the result is the same clip every time, and the fix here is structural rather than a bigger prompt: a required brief, a menu of styles, a menu of structures, and rules the agent can verify against its own output. What you get is a single file you can double-click, scrub with a query flag, and export frame by frame when you need a file for someone who does not have a browser open. The honest limits are the ones the package states itself: no releases, one open issue against a large audience, and a gallery whose example footage is openly fictional, which means the styles have to be judged on your own brand rather than on the samples.

Frequently asked questions

Official sources

1. bangtutorial/bang-motion on GitHub
2. Issues
3. License: MIT
4. README