video-production-skills

Fifteen agent skills, two host-side tools and a look library for producing video: short-form
ad campaigns, short films and music videos made from generated footage or from a client's own clips, and
narrated motion-graphics explainers drawn in code. The measurements behind the finishing rules are in the
references.

What is in the box

Each skill is a SKILL.md with the steps and their completion criteria, a references/ directory
with the contracts and measurements, and a scripts/ directory of small Python and shell tools.
Every Python and shell script prints its usage on --help and changes nothing, and the scripts that
work inside a project take its folder as --root <project>.

skills/ is generated from a separate source tree and exported here, so an edit made to it in this
repository is overwritten by the next export. Read it, run it, copy from it; to change a skill, open an
issue rather than a patch.

What you need

The base install is an agent that reads SKILL.md — Claude Code and Codex both do — Python 3.10 or newer
with numpy, Pillow, scipy and PyYAML (pip install numpy pillow scipy pyyaml), and
ffmpeg.
On Windows, run the kit inside WSL2. The skills give the agent bash commands, and WSL2 is where we built the kit.
AGENTS.md is the short orientation an agent reads before its first action; this file is the long form.

The table follows a production in the order it runs. Each row names a step and its skill, what that step adds
on top of the base install, and the key or variable it reads from .env. Set up the rows you will use. The
entry skill (video-production), pre-production (ad-spot-preprod, film-preprod), the prompt
(video-prompt-dialects), the cut (video-edit-edl) and the client round (client-rounds) need nothing
more, and the status line reads the balances of a Higgsfield subscription, monid and ElevenLabs once those are
set up. The Higgsfield API has no balance to read, so its row keeps the wallet in a local ledger. Three rows want a
GPU of your own, and how much VRAM it has decides which. If you have no GPU, or a small one is the whole answer in one place.

tools/README.md and look-library/GUIDE.md §5 walk through both Windows setups.

A real person in a reference narrows the routes, and the dividing line is whose face it is, not which venue
you pick. fal refuses any photoreal person, and monid's model host refuses real faces before generation starts.
The Higgsfield API and treg both generated from a photograph of an ordinary person, and both refused a
photograph of a public figure. treg refused it with its content filter switched off, so that switch relaxes the
check on ordinary faces and leaves the public-figure check in place. No venue checks whether you hold the rights
to a likeness; that clearance is yours.

ComfyUI, only for work on your own GPU

Install ComfyUI only if you want to run models on your own GPU, for MiniMax H3 seeds or the scene proxy.
Every hosted route works without it. Comfy-Org/ComfyUI lists the ways
to install it: the desktop app for Windows and macOS, a portable build for Windows, comfy-cli, or a manual
install. skills/video-refs-continuity/scripts/comfy_up.sh starts a manual install headless from the
COMFY_* variables in .env, locally or over ssh. With any other install, start the server yourself and
point COMFY_HOST at it; comfy_ready.py, in the same folder, names anything missing.

The scene proxy needs ComfyUI 0.31 or newer,
ComfyUI-Majoor-OmniCam in custom_nodes/, and two
checkpoints under models/: geometry_estimation/moge_2_vitl_normal_fp16.safetensors from Comfy-Org/MoGe
and checkpoints/sam3.1_multiplex_fp16.safetensors from Comfy-Org/sam3.1. The H3 recipe needs more, and
the next section lists it.

MiniMax H3 on your own GPU

Local seeds cost nothing, but each run holds the whole card. On a 24 GB RTX 3090 in a box with about
64 GB of RAM, the recipe renders a 5-second take at 768×1344 in about two minutes, and VRAM peaks at
23.9 GB. We have not tried a smaller card.

The speed depends on a PyTorch build for CUDA 13.0 or newer. Put it in a virtualenv of its own, so the
tools that depend on your current PyTorch keep theirs:

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu130

Those wheels run on RTX 20-series (Turing) cards and newer, with a driver that supports CUDA 13 (on
Linux, 580.65.06 or later). nvidia-smi prints the highest CUDA version your driver takes. On an older
build ComfyUI warns at startup that it needs cu130 for its optimized CUDA operations, and our take ran
2.1× slower.

ComfyUI provides the H3 nodes, the comfy-kitchen attention backend and the block-sparse attention node
the recipe uses, so you need no SageAttention build. We ran 0.35.0. Three custom node packs go into
custom_nodes/, each with its requirements installed into the same virtualenv:
ComfyUI-KJNodes,
ComfyUI-VideoHelperSuite and, for the ×2
master pass, Comfyui_Minimax_h3_latent_Upscaler.

Every weight is public on Hugging Face, about 45 GB for the recipe; hf comes with
pip install -U huggingface_hub.

cd ComfyUI
hf download Comfy-Org/MiniMax-H3 text_encoders/qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors \
  vae/minimax_h3_video_vae_fp16.safetensors vae/minimax_h3_audio_vae_fp32.safetensors \
  loras/minimax_h3_ref2v_turbo_4step_v0.1_comfyui_bf16.safetensors --local-dir models
hf download WarmBloodAban/Minimax-h3_Singularity \
  Minimax-h3_Singularity_ref2va_Pruned_v1.3_int8.safetensors --local-dir models/diffusion_models
# the ×2 master pass
hf download LBH-123-AI/Minimax_h3_latent_Upscaler \
  minimax_h3_latent_upscaler_3d_fp16.safetensors --local-dir models/latent_upscale_models

The sharpener pass adds loras/minimax_h3_lms_v1.0_r64.safetensors from Alissonerdx/Minimax-H3-ComfyUI
and the stock trunk that LoRA was trained on, diffusion_models/minimax_h3_ref2va_pruned_int8_convrot.safetensors
from Comfy-Org/MiniMax-H3. Every model carries its own licence. The kit ships no graph. Build yours from
skills/video-gen-cost-gate/references/LOCAL-H3.md, which has the settings and the measurements behind
them.

Caption fonts

The kit ships no fonts. build_captions.py loads a caption style's font from hyper/fonts in the project,
or from the folder --fonts-dir names, and stops if the file is missing. It knows three styles: A is
Bangers, saved as Bangers-Regular.ttf; B is Inter, saved as Inter.ttf; C is Nunito, saved as
Nunito.ttf. Style B sets the Black weight by name, so Inter has to be the variable font, and so does any
font you give a weight. All three are free on Google Fonts under the SIL Open
Font License, and Google Fonts is the place to look for more; each family's page shows its licence. To use
another face, put its TTF in the same folder and write the file name as font in the EDL's caption_style.

Topaz, only for upscaling on your own GPU

Install Topaz only if you want the local upscale. It does one job in the kit: a Rhea ×4 pass over approved takes
framed chest-up or closer, plus at most an Iris ×1 pass over a punch-in, on the GPU of a Windows machine that WSL2
drives. Without a card to spare, skip it and use the hosted upscale, which covers the same takes with Rhea on
Higgsfield credits or Starlight on fal, each behind a cost line. Our 4× Rhea run held an 11 GB card at 92% VRAM.

Topaz Video was called Topaz Video AI before the rename. The wrapper in
tools/topaz-upscale/ finds either one's install and model folders, and tools/README.md lists the variables that
override it. We measured it on Topaz Video AI 6.0.2 only. It drives Topaz's command line, which Topaz says it is
phasing out, so check a new release before a job depends on it.

What still works when a dependency is missing

Most of the kit degrades rather than stops, and it is worth knowing where, because the substitutes are not
always worse.

The rule the kit holds to: nothing you are asked to watch needs a build step. A master plays in any
player; a designed element's source is one HTML file a browser opens.

If you have no GPU, or a small one

"Do I have a GPU" is the wrong question — every local step has its own VRAM floor, and ours are measured,
not estimated. Find your row first.

Resolve's own floor is lower than ours — 2 GB VRAM and 16 GB system RAM — so it may well install on a modest card and
still be unable to carry the graded pass we measured, which held 92% of 11 GB. Treat "it launches" and "it can finish
a job" as separate questions.

On an APU those two floors compete for one pool. The iGPU takes its VRAM from the same system RAM Resolve wants
16 GB of, so a 16 GB machine satisfies neither floor comfortably once the carve-out lands. Leave the BIOS UMA buffer
at its default: it sets a minimum reserve rather than a cap, and raising it only takes RAM away from everything else.

Which Resolve licence you hold decides export speed more than the card does. On the free edition, H.264 and H.265
encoding is CPU-only — the GPU's hardware encoder is not selectable on the Deliver page — so exports are slow on any
machine, and slowest where that CPU is also feeding an iGPU. Studio uses the hardware encoder. The documented
workaround on free is to export an intermediate (DNxHR) and transcode that with ffmpeg, which does reach the encoder.

At ~11 GB, ignore only MiniMax H3 on your own GPU and buy your seeds
hosted. Keep tools/topaz-upscale/ and the Resolve chain — they are the two things that do fit. Expect
them to be slow rather than impossible: a Dehancer frame took 5.5 s at 3416×1920, and a full pass ran about
135 minutes.

Everything below applies to the last two rows — no card, one under about 11 GB, or a non-NVIDIA one.

Ignore three sections: ComfyUI,
MiniMax H3 on your own GPU, and
Topaz.

Five scripts cannot run. Nothing else calls them, so nothing else breaks — but read the note under the list:

skills/video-refs-continuity/scripts/comfy_up.sh
skills/video-refs-continuity/scripts/comfy_ready.py
skills/video-refs-continuity/scripts/scene_blockout.py
skills/video-finish-qc/scripts/upscale_local.sh
tools/topaz-upscale/topaz_upscale.py

tools/topaz-upscale/ is safe to delete in these rows only — at ~11 GB it is one of the few local things that still works. Leave every COMFY_*, TOPAZ_* and TVAI_* variable unset in .env.

One caveat on scene_blockout.py: it ran in ~15–25 s per frame on a 24 GB card, but that is the card it happened
to run on, not a measured requirement — its two checkpoints are small and nobody has tried it on a lesser card.
If you have some GPU, it is worth one attempt before you assume it is out.

You keep all fifteen skills and every generation route, because all of them are hosted: Seedance 2.5 on
Higgsfield by subscription or through its API, on monid or treg pay-as-you-go, and on fal for people-free
shots, plus kie for stills. You keep the
whole finish chain, with the hosted upscale doing the job Topaz would have done. And you keep look-library/,
because applying a look is an ffmpeg lut3d filter — Resolve is only needed to author or rebake one. The
phone-native finish is ffmpeg from end to end.

One METHOD changes, not just a tool. Without scene_blockout.py you cannot compute a room from a keeper
frame, so the geometry for a new angle is read off that frame at 2–4× zoom and copied into the prompt
verbatim, and the GO ask says "no scene proxy for this shot"
(skills/video-refs-continuity/SKILL.md § Failure behavior). The reader, scene_proxy.py, needs no GPU and
still works on any scene.json you already have.

tools/resolve-pass/ is a different axis, not this one. It needs Windows, DaVinci Resolve Studio and a
Dehancer licence whether or not you have a card. Without it a look still applies as a LUT; what you lose is
halation, bloom, grain and gate weave as a graded pass.

Install

git clone https://github.com/konradre/video-production-skills
cd video-production-skills && ./install.sh

The installer symlinks skills/* into ~/.claude/skills/. The skills find the tools and the look
library through those links, so the default layout needs no configuration. Every command inside the
skills calls ~/.claude/skills/<skill>/…, so keep those links whichever agent runs the kit; if your agent
loads skills from another folder, ./install.sh <that folder> links them there as well.

For Codex, that folder is ~/.agents/skills:

./install.sh ~/.agents/skills

That links both, and both are needed: commands inside the skills call ~/.claude/skills/<skill>/… by
absolute path, so that link stays load-bearing whatever agent you run. Codex then invokes a skill with
$<skill-name>, and reads AGENTS.md at the repository root on its own — it does not read this file.
Claude Code reads CLAUDE.md, which is a one-line import of the same AGENTS.md.

Vendor keys never live in the repo or in a skill. Copy .env.example to .env, which git ignores, and
fill in the keys for the parts you use. The file names every key and variable the kit reads and what each
one is for, including two fallback routes that no script calls. The scripts read keys from the
environment rather than from the file, so the agent loads it in the same command that needs it:

set -a; . ~/.claude/skills/video-production/../../.env; set +a

That path resolves through the installer's link to the root of your clone.

How a production runs

Start with /video-production and name the project root and the genre. The entry skill reads the
project's pause block, prints a status line (deliverable, free disk, balances where a vendor lets you
read them, background jobs, open items) and hands off to the phase the next step belongs to. The
phases run downhill and each one carries its own gate:

pre-production → references and continuity → the prompt → the gated generation call → the read →
the cut → the sound → designed elements → the finish and QC → the client round.

METHOD.md walks the whole method in order and says why each rule exists. A few of them bind every
turn, whatever the phase. A cost line and the operator's explicit go come before any billed call, and
the amount does not matter. Nothing is upscaled before the operator has approved the take. The
client's text is the single source of truth and additions are proposed as cost lines. Continuity is
the first acceptance test, before the gag. Masters are 1080p only. Decisions go to the operator as
numbered questions with the cost and the file path inline.

Every other house rule in the kit guides rather than blocks. It says what departing from it would cost, as a
number where one exists, recommends, and then does what the operator decides.

Seedance seeds generate at 480p and are upscaled only after approval, with one exception. A talking head that
has to speak a locked voice-over generates at 720p, with the voice-over passed as an audio reference on a route
that accepts one. The audio drives the words, so there is no lipsync pass, and the finish is a 1.5× lanczos
scale to 1080×1920 in place of a reconstructive upscale. Leave the words out of the prompt: written dialogue
outranks the audio and demotes it to timbre.

The phone-native finish

A creator-style spot, the kind that has to pass as something a person filmed on their phone, does not get
the film finish. It gets a tier of its own, ugc-phone, and that tier inverts two of the rules above on
purpose.

What makes a clip read as phone-shot is not its colour. A .cube carries colour only, and a phone's colour
is close to neutral, so the library's ugc-phone cube is a grade close to identity, with no film stock and
no split-tone, and there is no Dehancer pass at all. Halation, bloom and film grain read as film, and a phone
has none of them. The phone-ness is temporal, and most of it lives in the encode.
skills/video-finish/scripts/phone_native.py runs at delivery resolution, after the cube and the downscale.
It adds a slow exposure drift, a white balance that moves in steps the way a phone's auto white balance does,
an exposure jump at each cut, one to three pixels of handheld shake, and either fine noise like a sensor's or
a light denoise. Then it encodes the way a phone does: H.264 4:2:0, a closed GOP, BT.709 tags, at a bitrate
between 2.5 and 12 Mbps. None of it needs Resolve, Dehancer or a GPU. ffmpeg and numpy cover the whole tier.

The probe decides the dose, not the eye. skills/video-finish-qc/scripts/phone_texture_probe.py reads three
numbers off native centre crops of a clip at five points along it: the share of 8×8 blocks the encoder
flattened to zero variance, the noise floor of the flattest fifth of the blocks, and the median block spread.
Run it on the project's own real phone clips first, by scene class, then on the candidate, and move the dose
until the candidate sits inside the real clips' range. The numbers compare matched content. They are not a
threshold, and a number from one project says nothing about another.

The calibration run overturned the premise we started from. We expected to add noise. Two real phone clips,
as they arrived from a client through a platform re-encode at about 2.5 Mbps, read a noise floor between 0.1
and 0.7, with anywhere from none to a third of their blocks dead-flat depending on which frames the probe
sampled. Three raw 720p takes from a hosted generator read a floor of 1.8 to 2.0 and no dead-flat blocks at
all. The generated take carried more fine texture than the phone clips, not less. Adding noise moved it
further out of the band. A light denoise and a 2.5 Mbps encode moved it in, and the encode was the larger of
the two levers. So the layer carries a denoise arm beside the noise arm, and the probe decides the direction
per pair. On another generator, another raster or another set of real clips the direction can reverse; we
have measured one generator so far. The full table is in skills/video-finish/references/EVIDENCE.md.

The prompt side lives in skills/video-prompt-dialects/references/PHONE-NATIVE.md. The dialect attributes
the camera ("shot on a front camera, handheld, at arm's length") and never names the device, because a
video model tends to draw the noun you hand it. camera_clause.py --phone, in the same skill, prints the
clause. That rule reads more certain than its evidence. We have watched generators draw a negated noun, one
burning in captions it was told to leave off and another drawing a grid it was told to omit, while the
device name case comes from other practitioners' skills and we have not yet checked it against a control on
the same seed. The creative grammar for the sub-genre, hooks, structures, beats by duration, the variant
matrix and the four artifacts a spot ships with, is in skills/ad-spot-preprod/references/UGC-GRAMMAR.md.
The disclosure rules for creator-style ads on the large platforms and under the FTC endorsement guides are
in that skill's references/RISKS.md, written from the primary sources; three claims that circulate in the
write-ups did not survive that reading.

What is not here

Where a skill needs an example of a file shape, the example is a placeholder. The five looks ship
complete, cubes and .drx grades both; the phone tier's cube ships alone, because that tier uses no
Dehancer pass. The .drx files were authored on Dehancer Pro OFX 7.4 and
need a licensed Dehancer Pro 7.x with its film profiles downloaded, because a major version installs
as a separate plugin. The spectral base cubes the film looks were baked from are fetched, not
vendored; you only need them to rebake after editing a recipe. Third-party notices are in NOTICE.md.

License

MIT. The film looks' cubes derive from spectral base cubes in
ComfyUI-Darkroom (MIT, notices in NOTICE.md);
the designed elements render with HyperFrames
(Apache-2.0); the Resolve bridge comes from
davinci-resolve-mcp (MIT). The .drx grades hold
our own settings for the Dehancer plugin and none of its profile data. Cubes exported by Dehancer's own
LUT Generator are licensee-only and must never be published.