Pluviobyte/video-production-skills: an installable skill set for AI video agents

The problem: agents produce slide decks, not motion

The README opens with a complaint that most AI video output looks like a deck of static layouts rather than a continuous timeline. The repository's answer is to separate direction from production. Instead of asking one agent to both invent a visual language and render it, the library puts a meta-director in front: ai-motion-director takes a topic, script or brief, decides the motion metaphor, builds a beat graph, schedules components and assets, and applies what the README calls an anti-PPT gate before handing work to HyperFrames, Remotion, image generation or a specific video skill. The audience is narrow and specific. These are skills for Codex, Claude Code, Cursor and other agents that support a local skill directory or the Skills CLI. If you are editing in a timeline by hand, this repository is not aimed at you. If you are orchestrating an agent that keeps producing static frames, the four skills map onto four distinct stages: direction, recreation and QA, styled main video, and opener packaging.

Four skills, four production stages

The README's table is the clearest statement of scope. ai-motion-director sits at the direction layer and produces a motion thesis, beat graph and component plan. reference-video-replica-qc handles the recreation loop: it decomposes a reference video, recreates the motion, and pushes the result toward HyperFrames or Remotion components. dark-saas-magic-video is a style skill for dark SaaS and AI product shorts, described as Presenton-like magic UI with black space, purple glow, kinetic type, a gradient CTA and floating UI. black-white-text-opener is a generation skill for openings: near-black background, large white text typed character by character, a synchronised typing click, and a clean transition. The repository layout matches the table. At the top level there are four directories with those exact names, plus assets and docs. Each top-level directory is described as an independently installable skill, and each is expected to carry a SKILL.md plus any scripts it needs. The Python language tag on the repository suggests the supporting scripts are Python, though the README does not enumerate them.

Installing a skill and running the direction stage first

The README gives the install path through the Skills CLI rather than a package manager. The first command lists what is installable in the repository, so you can confirm the four skill names resolve before committing to one.

npx skills add https://github.com/Pluviobyte/video-production-skills --list

If the listing shows the four skills from the README table, install the one that matches your stage. The director skill is the natural first install, because the README positions it as the layer that decides motion metaphor and component routing before any rendering happens.

npx skills add https://github.com/Pluviobyte/video-production-skills --skill ai-motion-director

The README's own selection guide is the practical test for whether you installed the right thing. Give the agent a topic, script or brief and ask for a motion thesis, a beat graph and a component plan. If it returns a shot list of static layouts instead, the anti-PPT gate has not taken effect and the skill is not doing the job the README describes. For the recreation path, swap the skill name for reference-video-replica-qc and expect a decomposition of the reference plus a fidelity classification rather than a finished render. The README does not document an uninstall command, a version pin, or a rollback path for an installed skill.

Five fidelity levels, and why the top one is mostly out of reach

The most useful design decision in this repository is that reference-video-replica-qc refuses to treat recreation as a single pass or fail. The README splits fidelity into five levels: source-code consistency, rendered-frame pixel consistency, encoded-output frame alignment, visual alignment, and style alignment. Any pixel-level conclusion has to clear three gates in sequence, described as asset, runtime and delivery, each checked frame by frame, with MAE, temporal offset, boundary frames, PSNR, SSIM and hash evidence. That is a strict definition, and the README immediately narrows it: hand-written HyperFrames or Remotion recreations usually target visual-level alignment and parameterised component capture, not pixel identity. Read that as the honest boundary of the tool. If you need to prove an output is bit-identical to an encoded reference, the evidence chain the skill asks for is expensive and the README does not claim the hand-written path reaches it. If you need a motion pattern extracted, parameterised and reused, the five-level vocabulary tells you which claim you are actually making when you say a component is aligned. The README does not document what happens when a gate fails, only that samples locate failures and full frames approve them.

Where the library stops: rendering, archiving and frame-accurate style work

The design-boundaries section is unusually direct about what these skills do not do. ai-motion-director does not replace final rendering, frame extraction, subtitles, audio or archiving. It defines the motion thesis, beat graph, component and asset plan, and the anti-PPT gate, and then stops. dark-saas-magic-video is a style-level creation skill and is explicitly not for frame-by-frame recreation, so pointing it at a reference video and expecting a match is a misuse. black-white-text-opener is a generation skill: it requires typed character-by-character text with a synchronised typing click, and the README states it is not for reusing original footage or claiming pixel-level alignment. The other real constraint is the component contract. The repository's long-term goal is a motion component library, and each component is supposed to carry a description of what content it suits, what screen problem it solves, which input parameters it needs, how the timeline moves, which video segment it belongs in, and what alignment evidence and limitations it has. That is a documentation obligation per component, and it is the part most likely to be skipped in practice.

How it differs from Remotion or HyperFrames alone

Remotion and HyperFrames are the rendering substrates here, not competitors: the README names both as the targets that skills hand work to. The difference in approach is where the decision lives. Using Remotion directly puts the motion grammar in your head and in the source file, so every new video re-derives the same choices. This repository inserts a direction layer that decides the metaphor, the beat graph and the component schedule first, and a QA layer that classifies how close a recreation actually got. The cost of that layer is indirection: you are now maintaining skill directories, docs pages and component descriptions alongside your render code, and the README expects each new skill to ship a SKILL.md, a docs page, preview media and a row in the README table. If your output is one video, that overhead is not repaid. If you are producing a series and want the motion patterns to accumulate, the component contract is the thing Remotion alone does not give you.

Maintenance, licensing and what the repository does not say

The last push to the default branch was on 2026-07-14, which is roughly two months before this article, and the repository is not archived. That is recent enough to suggest the author is still adding to it, though no releases were retrieved, so there is no version history to pin against and no changelog to read before upgrading. The README describes the repository as long-term maintained and states an expansion policy: new skills are organised by director and scheduling, recreation and component capture, openers and packaging, styled main video, asset processing, and platform adaptation for Douyin, Xiaohongshu and WeChat video covers, aspect ratios and pacing. That policy is a plan, not a commitment, and the README gives no schedule. The licence is the sharper gap. No licence identifier appears in the README, and the repository metadata does not supply one. Until you confirm it, treat the component library you build on top of these skills as having unclear redistribution terms, and check the repository's licence file before shipping anything derived from it. Nothing here is legal advice; the point is simply that the terms are not stated in the README.

Editorial conclusion

Adopt it if you already drive Codex, Claude Code or Cursor against a local skill directory and you want the recreation loop to leave behind reusable HyperFrames or Remotion components rather than one-off renders. Skip it if you want a renderer or a standalone editor: the README states that ai-motion-director does not replace final rendering, frame extraction, subtitles, audio or archiving, and dark-saas-magic-video is explicitly a style-level skill, not a frame-accurate recreation tool. Verify three things before you build on it: that the npx skills CLI resolves the repository URL in your environment, that the per-skill SKILL.md files exist in the directories you install, and which licence the repository carries, because no licence identifier is stated in the README and that governs whether the component library you accumulate can be redistributed.

Frequently asked questions

Official sources

1. Issues
2. Pluviobyte/video-production-skills on GitHub
3. README