The description says fourteen skills, the README says fifteen

Fourteen in the description, fifteen in the list

The repository's one-line description advertises 14 skills, and the feature list in the README says 15 skills mirrored for both assistants, with their helper scripts and references. Two counts from the same author, one release apart at most, and the numbers do not match. It is the kind of discrepancy that usually means a skill was added without updating the description, and the mirroring makes it more interesting: every skill exists twice, once for Codex and once for Claude Code, so the count of skills is also the count of things that must stay in step. Nothing else in the README is ambiguous about scope. The rest of the inventory is specific: 406 draft motion-graphics cards across two styles with manifests, CSS tokens and editable slots, two scene templates described as dark graph paper and a left glass popout, 12 existing teaching projects preserved from the original kit, and a synthetic starter composition and editing fixture that need no footage and no API key.

Four commands on top of four prerequisites

Installation is a toolchain plus four commands. You need Node.js 22 or newer, Git, FFmpeg including ffprobe, and Chrome or Chromium, with node, ffmpeg and ffprobe on the terminal path. Then:

git clone https://github.com/nateherkai/hyperframes-student-kit.git
cd hyperframes-student-kit
npm ci
npm run setup
npm test

The setup step checks the tools and creates a .env file only if one is not already there, which is a small kindness: rerunning it will not overwrite keys you added. The README is explicit that you add only the keys for services you actually choose, and that the local starter needs no paid transcription or generation API at all. Running the test suite as part of setup is the step that tells you whether the FFmpeg build you have is one the tools can use, and doing it before you point the kit at a real recording is the cheaper order.

The demo renders a draft on purpose

The first render is deliberately a toy, and the README says so in three separate ways. The demo uses local GSAP, has no voiceover, and comes with a separate synthetic transcript that exercises the cutting tools while being explicitly fictional test data rather than a transcript of the animation. The sequence is:

npm run demo
cd video-projects/demo
npx hyperframes lint
npx hyperframes preview

You scrub the eight second animation in Studio, stop the preview with Ctrl+C, and render it at draft quality. That ordering matters for two reasons. Linting before previewing means the composition is checked before you spend time watching it, and the draft render flag means the first file you get is a proof rather than a delivery. One environmental note is easy to miss: HyperFrames may download and cache font substitutions on the first render, so the first run is slower than later ones and a machine with no network access will behave differently from one with it.

Three transcription paths and two generation services

The tools section describes what the author actually uses and what you can substitute. ElevenLabs Scribe does the transcription and Kie.ai generates videos and image assets, and the instruction is to bring your own API keys and credits for those services. Generated assets are optional. For transcription specifically there are alternatives: you can ask the assistant to use OpenAI Whisper or a local Whisper instead, or supply a word-level transcript you already have. The distinction between the built-in helper and the integrations is worth noting, since the included transcription helper uses ElevenLabs while Whisper and Kie.ai need the setup described in the tools guide. A word-level transcript matters because the cut tools and caption validators are timing-based: a transcript without word timings cannot drive precise caption placement, which is what several of the short-form validators check.

406 cards, two templates, and a searchable registry

The motion side is a library rather than a demo. 406 draft motion-graphics cards sit across two styles, each with manifests, CSS tokens and editable slots, and they are browsable two ways: a library guide describing the card set and design tokens, and a registry.json holding searchable card metadata. Two whole-scene templates ship alongside, dark graph paper and a left glass popout, which are the two looks the prompt examples reference by name. The design vocabulary is separated again into its own document, a motion and transition philosophy file, and shared agent instructions live in AGENTS.md at the root. So the structure is a vocabulary document, a token set, a card registry with manifests, two scene templates and an agent instruction file, which is the arrangement you would expect from someone who intends the output to look consistent across many videos rather than hand-tuned each time.

Two kits, two histories, one repository

The migration note is the most consequential line for anyone arriving from the older material. This repository is the main student kit, and the newer video-pipeline kit has been merged into it with both Git histories preserved. The original 12 projects remain in video-projects/ alongside the original shared brand examples, and three older skills are still there: make-a-video, short-form-video and website-to-hyperframes. The README tells you to use short-form-edit for new work, and describes short-form-video as documenting the older May Shorts compositions. So there are two skills with overlapping names and overlapping purposes, and the guidance is to use the newer one. Preserving both histories means git log is continuous across the merge, which is helpful for anyone who tracked the old repository, and it also means the tree contains a superseded skill that will still be found by search.

Where this kit is the wrong tool

Four cases. The first is someone who wants a video editor. There is no timeline, no trimming interface and no preview reel; the workflow is a prompt to an agent, a draft to review, and a command to render. That is a different shape from a desktop editor and it suits a different person. The second is a creator with no footage. The kit is built around bring your own footage, and the synthetic fixture exists to exercise the cutting tools rather than to be edited into something publishable. The third is anyone who needs reproducibility. Card output depends on an agent choosing among 406 options and a motion philosophy document shaping that choice, so two runs of the same prompt are not guaranteed to produce the same file, and the draft review step is what makes that acceptable rather than a problem. The fourth is a workflow where nobody reviews the output. The README repeats the instruction to review the actual motion and audio before publishing, and requires confirmation before any paid music or asset generation, which is the right posture for an agent that edits your words and spends your credits.

Editorial conclusion

The kit suits a creator who already records footage and wants an agent to propose cuts, build motion graphics and validate captions, and who is prepared to review every draft. It does not suit someone expecting a finished editor with a timeline, nor a creator working without footage. Before adopting, install Node 22 or newer with FFmpeg and Chrome, run npm run setup and npm test before pointing the kit at a recording, and read the migration notes since two kits with overlapping skills were merged into this repository.

Frequently asked questions

Official sources

1. Issues
2. nateherkai/hyperframes-student-kit on GitHub
3. README