motion-skills holds four files and no skills, and the README counts 54 where the repo description says 50

This repository contains four files and none of the skills

The most important structural fact is not stated anywhere in the README and is visible only from the file tree. The top level holds a licence, a README, a demo animation in two forms, and a tools directory. There is no skills folder here, no code, no examples you can run. All fifty-four skills live in seventeen separate repositories under the same organisation, one per audience, and this repository exists to list them. That has two consequences. Cloning it gets you nothing you can use, so installation is per pack and the README says so explicitly. And tracking changes across seventeen repositories is seventeen watch views rather than one, which is why nothing here has a version number to pin against and the project has published no releases at all.

The README says 54 skills and the repository description says 50

The two counts do not agree, and you can check which is right rather than guessing. The README header claims fifty-four skills across seventeen installable packs. The repository description, which is what appears on the project page and in search results, claims fifty skills across fourteen packs. The pack table is the tie-breaker: it lists seventeen rows and its skill column sums to exactly fifty-four, four plus one plus two plus three plus three plus three plus five plus one plus nine plus nine plus one plus five plus three plus one plus one plus two plus one. So the README is current, the metadata is two packs and four skills out of date, and the table agrees with the header. Anyone who installed from a search result rather than the README is looking at a smaller catalogue than the one that exists.

A skill is a folder of markdown, in the format agents already read

The format is worth understanding because it is not proprietary and the project is candid that it is not. A skill is a self-contained folder holding a manifest document and a references directory, and it teaches one workflow rather than one technique. The README is explicit about what it is not: no model fine-tuning and no plugin runtime, just the know-how in a format that major agents already read. That is the same manifest-and-references shape used across the current generation of agent tooling, which means these drop into whatever you already run without an adapter. Installation is one command per pack:

npx skills add iart-ai/tiktok-video-skills
npx skills add iart-ai/data-animation-skills

or a plugin marketplace command if you are on a client that expects plugins. Once present, the skills are discovered automatically and activate when your prompt matches the work.

The verify loop is the real content, and it needs tools you may not have

Every skill that produces a visual artefact ships a loop that renders a frame, takes a screenshot, and checks the result, plus a small toolkit of scripts for freezing a frame, tiling a contact sheet, and probing the encoded video. That loop is the substantive engineering in this project, because it changes what the agent is doing: it stops guessing whether a render is correct and starts looking. The cost is that it assumes a toolchain. Probing an encoded file implies a video probing binary on the path, and tiling a contact sheet implies an image library and a working renderer. A skill can therefore be perfect as documentation and useless in an environment without those binaries, which is a failure mode that looks like the agent ignoring the instructions rather than a missing dependency.

Two renderers, split by output type

The choice of renderer follows the artefact. Web skills render a standalone HTML file, which means the output is a single file you can open, screenshot, and hand to a browser, with no build step in between. Video skills render through one of two named programmatic video tools, and the split is not arbitrary: one is the general-purpose timeline tool and the other is the mathematics-oriented animation library. The pack list reflects that division, with a dedicated pack for mathematical and educational animation carrying a single skill, and separate packs for the web, WebGL and shader work, and JavaScript animation where every frame is drawn in code with no assets at all. If you are picking a pack, the renderer is usually the deciding factor, since it determines what you need installed before the skill can do anything.

Seventeen packs aimed at seventeen different audiences

The pack table is organised by who is making the thing rather than by technique, and the skill counts vary a lot inside it. The two largest carry nine skills each and go to frontend developers and to motion designers, which is where you would start if you already work in the medium. Below them, five skills for explainers and educators, five for freelancers and studios, four for short-form vertical video creators, three each for e-commerce sellers, brand advertisers, and analysts, and then a tail of single-skill packs for text-message stories, editorial map animation, kinetic typography, mathematical animation, generative illustration, and transparent lower thirds for streamers and editors. Fourteen of the seventeen are for a specific niche, which is a reasonable way to keep a general catalogue from becoming unwieldy, and also means most people should install one pack rather than the set.

Triggering is prompt matching, and the agent count is a claim

The activation story is one sentence: installed skills are discovered by the client and activate on their own when the prompt matches the work. That is a strength and a limitation. It means there is nothing to invoke manually, which removes a whole class of friction, and it also means you cannot force a specific skill when the match is ambiguous, so a request phrased unusually may quietly not load the guidance you wanted. The client coverage claim is worth reading carefully: a named set of clients plus forty more, discovered automatically. Nothing in the repository demonstrates that, and the compatibility surface is entirely the manifest format, so the practical test is whether your client reads that format rather than whether anyone counted.

The skills are the open subset of a hosted product

The README positions these as the open-source craft behind a commercial service, and the links carry campaign parameters so the traffic is measurable. It offers two paths: bring the skills into the agent you already use, or let the hosted service run the whole pipeline, which is described as taking a prompt or a file and returning editable motion graphics with exact text and numbers. That framing explains the structure. Skills that encode judgement, timing, safe areas, and easing are the part a user can run anywhere, so they are published. The rendering service is the part that needs infrastructure, so it is not. It also means the licence covers the knowledge rather than a tool, and there is no compatibility commitment between a skill written for one renderer and a future version of that renderer, which is the usual maintenance cost of instruction sets rather than code.

Editorial conclusion

Install one pack rather than all of them, because the packs are genuinely aimed at different audiences and the largest two are nine skills each. Read the verify loop before you trust the output, since it is the part that distinguishes these from prose instructions and it depends on tooling you may not have. And note what the counting tells you: the repository description is two releases behind the README, so anything you read off the project page rather than the README may be stale.

Frequently asked questions

Official sources

1. iart-ai/motion-skills on GitHub
2. Issues
3. License: MIT
4. Project website
5. README