Who is behind TopDigg?

TopDigg is created by Eric, a researcher focused on AI trends and SEO/GEO strategies.

How often is content updated?

Blog posts are published regularly. AI Daily is updated daily with the latest AI news.

Can I republish or share content from TopDigg?

Please contact us for content licensing and collaboration inquiries.

anything2explainer Deep Dive: Give It a Topic, Get a Code-Drawn Explainer Video

Prologue: You want AI to explain something clearly, but video is a pain

Consider a very concrete request.

You just finished reading a paper, or you just finally understood a technical concept, and you want to post a three-minute explainer video to 视频号 (WeChat Channels). The topic is picked and the script is roughly written. What's blocking you now is: what about the visuals?

Find stock footage? The licensing is murky, and footage stitched together will never stitch into a film with logic. Use an AI video generation model? Right now the generated clips don't join up, the text comes out wrong, and everything drifts on every frame. Use a talking-head digital human? Technically fine, but a talking head never explains any mechanism — it just reads the script.

Step back one more step: let an AI coding agent write the code that draws every frame?

The direction is right, but you immediately hit a second problem: Remotion itself only gives you a canvas; it does not tell you what a film should look like. The first agent produces a beautiful shot, the second agent's output looks like a slide deck, and the third forgets where the subtitle band goes. Stitch together the output of five agents and it looks like five different companies made it.

So how should this be done?

anything2explainer's answer is very direct: don't just write the code, write down the whole methodology too. It breaks down "how to shoot an AI-generated explainer video" into a style guide, a motion vocabulary, hard rules for composition and light, an agent division-of-labor protocol, quantified QC scripts, plus one complete sample film as the quality yardstick.

This is not a command-line tool you can run. It is more like a filmmaking manual written for AI.

1. Project Description: What's Actually in the Repository

1.1 One-Line Positioning

Input a topic, or an article you want to turn into a video, and get a 1280×720 H.264 MP4: with TTS narration, word-aligned subtitles, chapter cards, a top HUD and a bottom chapter progress bar, in Chinese or English.

The key point is that every frame is drawn by code. There is no asset library, no generative video model, and not a single frame taken from anyone else's video.

The author, Vincentwei1021, lists it as "software" in CITATION.cff, published on 2026-09-09, licensed under PolyForm Noncommercial 1.0.0: free for non-commercial use, commercial use requires prior authorization, but whatever you make with it belongs to you.

1.2 It Is Not a CLI

This deserves its own section, because many people will try it as a tool and then conclude "nothing happened."

What the repository ships is the complete methodology for getting an AI coding agent to produce the film. Only three things actually get executed:

A compilable Remotion 4 template project (template/), which you copy into a working directory with new_project.sh;
A stack of specification documents written for the main session and the individual agents (reference/);
One finished sample film (examples/rag/), together with its research draft, narration script, storyboard, the source code for 44 shots, and 5 QC reports.

The author put a Claude Code badge and a Codex badge on the skill, meaning it is a "skill package" loaded by these two kinds of agents — not software you type commands into.

1.3 Repository Structure at a Glance

SKILL.md                  流程主干：9 个阶段、4 个确认点、质量标尺
reference/                写给主会话和各 agent 的规范
  style-guide.md            安全区、调色板、字体、图元目录、版式规律
  motion-vocabulary.md      入场/强调/光效/离场/运镜的公式与帧数
  composition-and-light.md  主体尺寸三档、光跟主角、高光时刻编排、QC 量化判据
  narration-guidance.md     口播文案写作原则（纯英文，已译中文）
  narration-storyboard.md   解说词格式与预算、配音参数、分镜令牌、镜头模式表
  research-brief.md         研究员 prompt 与事实规则
  agent-build-rules.md      构建 agent 协议
  agent-qc-rules.md         QC agent 协议
  prompts.md                六种 agent 的 prompt 模板
  lessons.md                五部片子的踩坑记录与根因
template/                 可编译的 Remotion 4 工程
  src/common/               雾底、星点、点阵波、glitch、缓动、字幕、进度条
  src/ui.tsx  src/fx.tsx    图元与调色板/光效、纵深、运镜图元
  src/overlay/              片头、章节卡、HUD、流程轨、片尾
  scripts/                  配音、分镜、still、测渲、渲染、QC 度量脚本
examples/rag/             样片全套纸面文件与成片帧
examples/contrast/        6 组反例/正例帧对照

In English: SKILL.md is the main spine of the process (9 stages, 4 checkpoints, quality yardstick); reference/ holds the specifications written for the main session and each agent — style-guide.md (safe area, palette, typography, element catalog, layout rules), motion-vocabulary.md (formulas and frame counts for entrance/emphasis/light/exit/camera move), composition-and-light.md (three subject size tiers, light follows the hero, set piece choreography, QC quantitative criteria), narration-guidance.md (narration writing principles, pure English with a Chinese translation added), narration-storyboard.md (narration format and budget, voiceover parameters, storyboard tokens, shot pattern table), research-brief.md (researcher's prompt and fact rules), agent-build-rules.md (build agent protocol), agent-qc-rules.md (QC agent protocol), prompts.md (prompt templates for six kinds of agents), lessons.md (pitfall log and root causes from five films). template/ is a compilable Remotion 4 project: src/common/ (fog backdrop, star dots, dot-field wave, glitch, easing, subtitles, progress bar), src/ui.tsx and src/fx.tsx (elements with palette/light effects, depth, camera move elements), src/overlay/ (intro, chapter cards, HUD, process track, outro), scripts/ (voiceover, storyboard, still, test render, render, QC metrics scripts). examples/rag/ holds the full paper trail of the sample film plus its rendered frames, and examples/contrast/ holds 6 groups of counter-example / positive-example frame pairs.

examples/contrast/ is particularly worth noting: it is effectively a scoring sheet. On the left are frames from another film the author made with the skill on 2026-09-08, 《eCPM 与广告竞价》 ("eCPM and Ad Bidding"); on the right are frames from the sample film 《RAG 与知识库》 ("RAG and Knowledge Bases"). Six side-by-side pairs, each pointing at a specific defect: the hero is too small, the hero has no light, the set pieces are not choreographed, the result item's text is too small, the background is littered with confetti, and the ending has no symbolic object.

1.4 How It Differs from Other Tools

The author provides his own comparison table, and I take it as the basis for tool selection:

Tool category	Output	What anything2explainer does differently
Generative video models (Sora, Veo, Runway)	Synthesizes assets from a prompt	The output is deterministic code, not pixels. Every number on screen can be traced to a source URL, and any single frame can be fixed by editing one shot file
Digital human / presenter tools (HeyGen, Synthesia)	A digital presenter reading a script	No presenter. Use motion graphics to explain the mechanism, with the narration driving the visuals
Hand-written Remotion / Motion Canvas	A programmable video canvas	It delivers a full methodology on top of the canvas: research → narration → storyboard → parallel build → QC, with a style guide, a motion vocabulary, and a sample film as the yardstick
Manim	Python math animation	An agent-driven end-to-end pipeline with TTS-aligned subtitles, chapters and QC; React / TypeScript instead of Python

That "no presenter" decision in the second row matters far more than it sounds. A digital human video carries essentially zero visual information — you just read the script out loud. Motion-graphic explanation, on the other hand, can show structure, order, and quantity at the same time. The README has a very well-put line: narration carries the reasons, consequences, comparisons and judgments; the picture carries structure, order and quantity.

2. Core Ideas: Why Insist on Drawing with Code

2.1 Three Non-Negotiable Principles

First, everything on screen is drawn in code. Optional live-action B-roll is allowed only from royalty-free sources, and must be registered in a MANIFEST (sha256, source URL, license, purpose). No frames or clips from any existing video may be used.

Second, every fact must have a source. Every number, year, organization, person's name and English term that appears on screen must be traceable to a source URL in that film's research doc. Anything the research did not verify goes neither on screen nor into the voiceover.

Third, one running example for the whole film. The narration and the visuals use the same example from start to finish. The sample film uses a "travel expense reimbursement" scenario: the question is 「差旅报销的上限是多少？」 ("What is the cap on travel expense reimbursement?"), the hallucinated answer is 「每天 1000 元，全国统一」 ("1000 yuan per day, nationwide uniform"), and the correct answer is 「住宿上限每天 600 元[1]，一线城市 800 元[2]」 ("lodging capped at 600 yuan per day[1], 800 yuan in tier-one cities[2]"), sourced from 「员工手册 p.12」 ("Employee Handbook p.12") and 「差旅补充规定 2025」 ("Travel Expense Supplementary Rules 2025"). All groups share the same example text — this is a hard constraint.

The second principle is the most valuable design decision in the whole project. Because a video's audience cannot click a source, the moment a number is wrong, it is simply wrong, and the cost of correction is far higher than in an article. Turning that into "if the research stage did not verify it, it may not go on screen" is far more reliable than trying to read text back out of pixels afterwards with QC.

2.2 What "Drawn with Code" Actually Buys You

This is the key to understanding the project. Video generation models and code rendering both look like "letting the computer draw the picture", but what they buy you is completely different.

Determinism. Every animation is a pure function of the frame number, randomness comes from a seeded rnd(...), and text widths are computed rather than measured in the DOM. So re-rendering produces exactly the same frames. Video generation models cannot do this: the same prompt run twice gives you two different things.

Editability. If any shot has a problem, the agent changes one number in one SCxx.tsx file and re-renders. Video generation models cannot do this; you can only regenerate the whole segment, without any guarantee that this time it will be better.

Traceability. Every number on screen can be traced to a URL in the research doc, because the picture was "drawn" from that document in the first place.

Verifiability. This is the most underestimated one. Because the picture is code, it can be statically analyzed. selfcheck.py can, without rendering anything, scan all shot source code, count how many flicker events there are, reconcile them against the whitelist in the storyboard, and extract every literal string that will appear on screen and reconcile it against the fact list. Those three checks take a few seconds to run, and they catch things the QC agent — which inspects pixels — cannot see, because it never sees the frames that were not extracted. The author puts it bluntly in lessons.md: these three checks catch exactly the problems that QC cannot find in pixels.

2.3 A Counter-Intuitive Judgment

Many people's first reaction is "AI video should use a generative model; code rendering is the old way". The author rebuts that with a set of data.

He compared his own 《eCPM 与广告竞价》 ("eCPM and Ad Bidding" — made with the skill) against the sample film 《RAG 与知识库》 ("RAG and Knowledge Bases") frame by frame. The two films have nearly identical motion-event counts, pacing, and total glow area:

Metric (finished film, frame by frame, content area)	Ad bidding	RAG sample
Average per-frame change / motion events per minute	0.47 / 72	0.56 / 76
Median of the largest object height	172px	219px
Share of time with the largest object <110px lasting ≥1.5s	29%	12%
Source code light-effect words halo / sweep / ghost	0 / 0 / 0	14 / 12 / 5
Source code skew / perspective / rotate	1 / 0 / 4	7 / 1 / 15

The entire gap sits in three things — "how big to draw the subject, who gets the light, how the set pieces are choreographed" — and has nothing to do with "how much motion there is".

This explains a trap many people fall into: the first version of the skill wrote down disciplines such as safe area, whitelists, exit to zero, and beats. The new film was actually better on those points, but "how large the subject should be and who the light should land on" lived only in the head of the person who made the sample film. The result: a small, dim picture that still looked bad after four rounds of QC.

The fix is not more motion, it is hard rules. That is the entire reason composition-and-light.md exists.

3. Detailed Tutorial: Running a Film End to End from Scratch

Below is the complete 9-stage process. Stage 0 through stage 8, plus the 4 checkpoints interspersed along the way.

3.1 Stage 0: Set Up the Project (5 minutes)

git clone https://github.com/Vincentwei1021/anything2explainer.git
ln -s "$PWD/anything2explainer" ~/.claude/skills/anything2explainer   # Claude Code
ln -s "$PWD/anything2explainer" ~/.codex/skills/anything2explainer    # Codex

Dependencies:

# Node ≥18（模板的 npm install 会装 remotion 4.0.507 / react 19）
brew install ffmpeg          # 抽帧 / 转码，必需

python3 -m venv ~/.venvs/a2e && source ~/.venvs/a2e/bin/activate
pip install 'edge-tts==7.2.8' numpy pillow scipy   # edge-tts 必须锁版本

The pinned version of edge-tts is not obsessive-compulsiveness. The README says it plainly: it tracks a Microsoft endpoint and breaks across versions, and after 7.2.0 you need to explicitly request word boundaries. scipy is only used by frame_metrics.py.

If you are only making an English film, also install kokoro soundfile and espeak-ng.

The author also verified it on Raspberry Pi and ARM machines, where there are three differences: the scripts use #!/bin/zsh so zsh must be installed; Remotion has no linux-arm64 headless browser, so you point it at the system Chromium (REMOTION_BROWSER_EXECUTABLE=/usr/bin/chromium); and kokoro will not install on ARM (it pins an old numpy and pulls in spaCy, while blis has no aarch64 wheel), so you fall back to kokoro_onnx or piper.

Create the project:

template/scripts/new_project.sh ~/work/my-video myslug

This copies the template, runs npm install, and runs tsc. This step eats about 2GB of disk; the README suggests running df -h and keeping 5GB free.

For an English film, also change lang in src/config.ts to 'en'. The backdrop defaults to a dot-field wave (bg: 'dots'); for the star-dot fog backdrop of the early sample film, change it to 'stars'.

3.2 Stage 1: Research (20 minutes, 1 agent)

Send out one general-purpose agent with WebSearch / WebFetch, and have it produce research/调研.md following the template in reference/research-brief.md.

The research doc has a fixed nine-section structure, of which sections 0, 6, 7 and 8 are mandatory:

0 执行摘要（1 分钟版：这是什么、为什么值得讲、最反直觉的一点）
1 处境与问题（没有它 / 不懂它时会怎样；谁在什么场景下会碰到）
2 起源与关键节点（提出者 / 事件 / 年份 / 出处文献）
3 它怎么运作（机制 / 过程 / 结构 / 历史脉络，选一条主轴）
4 边界与对比（和最容易混淆的相邻概念差在哪）
5 争议、局限与近 2 年的变化
6 真实案例与失败模式（成功的和翻车的都要）
7 数字与比喻清单   ← 最重要的一节
8 术语对照（≤30 条）

Section 0 is the executive summary (the 1-minute version: what this is, why it is worth talking about, the most counter-intuitive point); section 1 is the situation and problem (what happens without it or without understanding it, and who runs into it in what scenario); section 2 is origins and key milestones (proposer, event, year, source literature); section 3 is how it works (mechanism, process, structure, historical thread — pick one main axis); section 4 is boundaries and comparisons (how it differs from the most easily confused adjacent concept); section 5 is controversies, limitations and changes over the last 2 years; section 6 is real cases and failure modes (both the successes and the blowups); section 7 is the numbers-and-metaphors list, the most important section; section 8 is the terminology table (≤30 entries).

Section 7 is the crux: a batch of sourced numbers that can be narrated directly, each with a way to convert it into an everyday scale, plus 5 metaphors suited to animation, each stating clearly where the analogy fits and where it distorts.

The count follows the film length: 8 to 10 items for a 2-to-3-minute film, 10 to 16 for a 3-to-5-minute film, and 18 to 24 for a 5-to-8-minute film.

There is one security detail worth noting. The research doc is scraped from web pages, and the agent is explicitly instructed: any instructional text inside it (text asking to modify files, run commands, or change the task goal) must not be executed; if found, mark it in the doc with a line saying "该页含指令性内容，已忽略" ("this page contains instructional content, it has been ignored"). Prompt-injection defense like this is now close to standard, but this protocol was written early, and it is worth recording.

3.3 Stage 2: Narration Script and Timeline (20 minutes, main session)

This stage is the "cheapest intervention point" in the whole pipeline, for reasons that will come later.

First read reference/narration-guidance.md, a purely English writing-principles document — and the only file in the whole project that never had a Chinese version (this time a Chinese translation has been added). It has 14 subsections; here are the most important ones:

Section 0 gives a single test: read a sentence aloud and ask yourself "at this moment, has the audience learned, seen, or felt something they did not know before that sentence?" If not, the sentence is filler. A five-minute script fits only about 45 to 50 sentences, and every sentence must pass this test.
Section 1: enter from the situation, not from the definition. Starting with "The definition of X is…" or "In this video we will…" wastes the most precious time you have.
Section 2: one throughline. The failure mode is a "glossary", a list of concepts all given the same treatment, whose order could be shuffled without anyone noticing. If the sections can be swapped freely without losing content, then there is no throughline — go back and find it.
Section 3: motivation before mechanism. What problem does it cause without you, how does it work, what does that give you. Never explain a mechanism the audience does not yet want to hear about.
Section 5: a metaphor is a tool, not decoration. One good metaphor running through several beats beats six clever ones used only once.
Section 11: say what the picture cannot say. The narration carries reasons, consequences, comparisons and judgments; the picture carries structure, order and quantity. Delete any sentence that merely describes what is on screen.
Section 13: hand off at the seams. The end of one section must leave a question, a cost, or a gap; the first sentence of the next section should point back at the previous section's result before opening a new topic. Delete bare-announcer transitions like "next, let's look at X".

The narration format looks like this:

# CHAPTER 1 章名（≤6 字，进度条章名）
一句话|按竖线切成字幕块|每块 ≤16 字        ← 一行一句
同一段的下一句                                ← 段内句之间只隔 10 帧
                                              ← 空行 = 段落分隔：一段 = 一个镜头
新的一段（= 下一个镜头）
## gap 20                                     ← 可选：额外插空白

In English: # CHAPTER 1 <chapter name> (≤6 characters, the name shown on the progress bar); then one sentence per line, with | splitting it into subtitle blocks of ≤16 characters each (the ← markers are the original's annotations: one sentence per line; only 10 frames between sentences inside a paragraph; a blank line means a paragraph break, and one paragraph equals one shot; a new paragraph means the next shot; ## gap 20 is optional extra blank space).

The vertical bar only splits subtitles; it does not affect how the text is read aloud. The blank line is the shot boundary, and that one rule is the foundation of the film's whole structure.

The sample film's narration opens like this — you can feel the pacing directly:

大模型很聪明|但它有三个天生的短板
第一|它的知识有截止日期|训练之后发生的事|它一概不知
第二|它读不到你公司内网里的文档|也不知道你昨天刚写的会议纪要
第三|遇到不知道的问题|它不会说我不知道|而是一脸自信地编一个答案|这就是幻觉
怎么办|重新训练一遍|成本太高|而且明天数据又变了
于是工程师们想出了一个办法|让模型开卷考试
考试前先把资料整理成一本手册|答题时先翻手册|再作答
这套方法就是今天的主角|RAG|检索增强生成

In English, the same passage reads:

Large models are smart|but they have three inherent weaknesses
First|their knowledge has a cutoff date|anything that happened after training|they know nothing about
Second|they cannot read the documents on your company intranet|and they do not know the meeting notes you wrote yesterday
Third|when they hit a question they do not know|they will not say "I don't know"|instead they confidently make up an answer|this is hallucination
So what do we do|Train it all over again|The cost is too high|and tomorrow the data will have changed again
So the engineers came up with an idea|let the model take an open-book exam
Before the exam, compile the material into one handbook|while answering, look up the handbook first|then answer
This method is today's protagonist|RAG|Retrieval-Augmented Generation

Notice that not a single sentence introduces a concept; it is all about the situation.

Checkpoint 2 is right here: paste the full narration, the chapter breakdown, the word count and the estimated duration to the user and ask "is this version of the script okay?". The chapter names and the HUD subsection names are listed on their own line, because those are the only words that appear on the progress bar — and the author gives a three-question self-check: looking at only these words, can someone who has not seen the film say what each chapter covers? Is each one a noun phrase? Put together, do they form a throughline a viewer can follow?

The author wrote counter-examples on purpose. The sixth film was called out by a user: its progress-bar chapter names were 「感觉还行 / 搭台留痕 / 两把尺子 / 诊断与证明」 ("feels alright / staging leaves traces / two rulers / diagnosis and proof") — evaluation sentences and quips, and a viewer glancing at them cannot guess the content. The positive example is the sample film's 「为什么要RAG / 知识库构建 / 检索与生成 / 评估与进阶」 ("Why RAG / building the knowledge base / retrieval and generation / evaluation and advanced topics"). Copy those out and hand them to someone who has not seen the film, and they can still say what each chapter covers.

Checkpoint 3 asks one more question right after: "do you have a preferred TTS for the voiceover?". If not, use the defaults: Chinese edge-tts zh-CN-YunxiNeural (Yunxi, male voice, original speed with no acceleration, roughly 5.5 characters per second), and English kokoro-82m am_liam (Liam, male voice). If there is a preference, generate the final wav with your own TTS, drop it into public/assets/<slug>/audio.wav, then fill in src/common/timeline.ts and subs.ts by hand — the rest of the pipeline stays exactly the same.

Then run the voiceover:

python3 scripts/tts_build.py

It synthesizes sentence by sentence, uses WordBoundary to cut the subtitle blocks, and outputs the voiceover wav, a frame-level timeline and a subtitle table. The pause strategy is written into the script: 10 frames between sentences inside a paragraph, plus 20 more frames at the paragraph end, and 45 frames before a chapter.

Pauses go only at the paragraph end, never after every sentence. This one rule was forced by user feedback: pausing after every sentence makes the whole film feel sluggish. A 30-frame paragraph end is roughly 1 second, so the viewer feels "this sentence is done, and the picture has settled too", and only then does the shot cut.

The script also lists, in the terminal, the paragraph-end sentences whose last block is shorter than 45 frames, marked with ¶. Those sentences need a ## gap 15-30 afterwards, or, during storyboarding, the final-beat element should be hung in front of the previous block.

After running, check whether the finished length falls in the interval the user asked for; if it is off by more than 15%, add or remove sentences and re-run rather than forcing it by tweaking the speech rate.

Then freeze it. After the script is final, no more word edits: every shot's frame numbers are hardcoded in the build group's code, so changing a single word means re-aligning the entire film.

3.4 Stage 3: Storyboard (25 minutes, main session)

Write script/storyboard_src.md, using tokens instead of frame numbers, then render it into 分镜表.md:

python3 scripts/render_storyboard.py

Tokens look like this: {S12.from} {S12.to} {S12.c3} (the start frame of the 3rd subtitle block) {C2} (the start frame of chapter 2) {TOTAL}, and they can carry an offset, e.g. {S12.from-8}.

One line per shot, with the columns: shot / frames / beat / visual / motion / hero · size / light.

The last two columns were added later, and that turned out to be the single most valuable revision. Originally the storyboard only had "visual" and "motion", so the build group had no idea how large the subject should be drawn or who the light should go to; the result was a median subject height of only 172px and heroes that were all unlit white wireframes. After adding those two columns, the sample film reached 219px.

Every line in the motion column must end with a 「持续：…」 (sustain) and a 「停留：…」 (hold) clause:

Sustain: which action carries this subtitle block's verb to the next beat (data flow, a pulsing light point running along an arrow, line-by-line typing, cell-by-cell lighting up, growing, rotating, a gate opening and closing, a queue compressing). For shots with no other camera move, write 「1.0→1.05 slow push」. Never write float, drift, or breathe.
Hold: the number of frames from the final-beat element's settle frame to the start of its exit, ≥30, target 30 to 45. If it is short, pick one of three: hang the final-beat element in front, go back to the script and add a ## gap, or merge it into an adjacent shot.

The 「全局约束」 (global constraints) section at the end of the storyboard must cover seven things: the example context, the fact list, the glitch whitelist, the list of reusable elements, the chapter boundary list, the set piece list and the light-sweep whitelist — plus the full text of the §9 rules on sustained verb action and settle-and-hold.

3.5 Stage 4: Overlays and Elements (10 minutes, main session)

The template ships with an intro, chapter cards, a HUD, a process track and an outro; the element library lives in src/ui.tsx, and the light-effect and camera-move elements live in src/fx.tsx. You only need to add 2 to 5 semantic icons for your topic.

The sample film added DocIcon (document), DBIcon (database), ChunkCard (text chunk), LLMIcon (large model).

Then produce a still and take a look:

scripts/still.sh Overlay 40,<章节卡帧>,<有轨帧>,<片尾帧> <绝对路径> ov

3.6 Stage 5a: Sampling (15 minutes, 1 agent)

Send out only G1 (the first half of chapter 1), and once it is done, render the first 30 seconds:

scripts/preview.sh 30

This is checkpoint 4. Everything the user wants changed (palette, font size, speech rate, intro, example context) gets fixed in one pass here.

The author's judgment on this point is extremely clear-eyed: changing it here costs one group, while changing it after the whole film has been rendered costs all the groups.

3.7 Stage 5b: Parallel Build (40 minutes, one agent for each remaining group)

The number of groups follows the film length; the sample film tier uses 8 groups, G2 through G8. Each group handles 5 to 7 shots, one file per shot at src/shots/Gn/SCxx.tsx.

Dispatch using the build prompt in reference/prompts.md, attach reference/agent-build-rules.md, and explicitly name G1 as the accepted style sample for them to read.
There are several hard constraints here, ones the build protocol repeats over and over:

Frame number N = useCurrentFrame() + F0. Every animation is a pure function of N, randomness uses only rnd(), Math.random is banned, and you should not use useState / useEffect for animation.
You may only modify src/shots/Gn/**, and must not touch Main / Root / common / other groups.
Before a hard cut, the exit must go to zero: use opacity = 1 − (n/N)^1.5, do not use a per-frame 6.7% exitFade (it would still leave 40% to 60% on the last frame and produce a visible "pop").
The entrance trajectory must not cut through the subtitle band: sliding in from below allows Δ ≤ 120; if you need to come in from off-screen, use a lateral slide-in with Δ 260 to 320.
Performance red lines: feConvolveMatrix is banned, filter: blur() must have σ ≥ 1, single-frame DOM nodes ≤ 600, SVG filter instances ≤ 6. Violating these makes the whole render 10 to 50 times slower.
Before wrapping up you must run npx tsc --noEmit, produce at least 6 stills per shot, do a 30-frame test render, and run python3 scripts/motion_check.py <Gn>.

The last one is the newest, and it quantifies sustained verb action and settle-and-hold: the longest static stretch per shot is ≤3 seconds, and the stable period on the final beat is ≥30 frames.

3.8 Stage 6: Rendering (5 minutes)

npx tsc --noEmit
VER=v1 scripts/render.sh

8000 frames is about 4.5 minutes of finished length, rendering takes 3 to 4 minutes, concurrency 6. The output is renders/<slug>_v1.mp4 plus fin_frames/.

Then the main session stitches 6 contact sheets together and reads them through itself, then runs:

python3 scripts/frame_metrics.py --out qc/frame_metrics_v1.md

What this measures: maximum object height per shot, hero-region glow area, purple fragment index, static segments.

3.9 Stage 7: QC and Fixes (60 to 90 minutes)

One QC agent per chapter, running against reference/agent-qc-rules.md, producing qc/qc_v1_Cn.md. Fixers are assigned by group, and one agent only fixes one to two groups.

Render v2, two re-verification agents check the v1 issues item by item plus do a regression read-through, make small fixes, render v3.

The final check does four things: glitch whitelist scan, light-sweep whitelist reconciliation, frame_metrics re-review of composition and light, and a motion_check re-measurement on the finished film.

The author emphasizes one thing repeatedly: passing motion_check at the group level is not the same as passing on the finished film. In film four, all 48 shots passed at the group level, yet the finished-film re-measurement found 11 shots over the limit: 3 were truly static and 8 had only small-area motion. The reason is that group-level rendering is low resolution, so the readings come out loose. That is why the finished-film re-measurement is mandatory in the pipeline and cannot be skipped.

3.10 Stage 8: Delivery

Produce 交付说明.md: the finished film, the voiceover source, the fact sources, the sample context, the QC conclusions, known retained items, and the table of contents. The default end-card signature is built by Anything2Explainer skill; setting config.builtBy to an empty string removes it.

Then write new lessons back into reference/lessons.md. This one step turns the whole repository into a continuously learning system — the lessons from the previous five films are still lying in there.

4. Multi-Agent Division-of-Labor Protocol: How Many Agents Does One Film Need

This is the most "engineering" part of the whole project, and the part others cannot simply copy over.

4.1 Six Roles

reference/prompts.md defines six agent prompt templates. Together with research-brief.md and the two rule documents, that is eight files making up the complete scheduling protocol.

Role	Count	Responsibility	Output
Researcher	1	Verify facts using WebSearch/WebFetch	`research/调研.md`
Build group	8 (sample-film tier)	5–7 shots per group, one file per shot	`src/shots/Gn/**` + `BUILD_NOTES.md`
QC	1 per chapter	Frame-by-frame check against written criteria	`qc/qc_vN_Cn.md`
Fixer	1 per 1–2 groups	Fix the items listed in the QC report	Code + a BUILD_NOTES appended section
Re-verifier	1 per two chapters	Check whether v1 issues are really fixed + regression read-through	`qc/qc_vN+1_recheck_C*..md`
Final check	1	Glitch compliance, light-sweep whitelist, frame_metrics, motion_check on the finished film	`qc/qc_vN_final.md`

4.2 The First Discipline of Dispatch: One Agent Gets One Heavy Job

The author wrote this into lessons.md as a hard rule: building 5 to 7 shots counts as heavy work, QC on one chapter counts as heavy work, fixing 1 to 2 groups counts as heavy work. The second assignment should only be light work.

The reason is that he hit this trap himself: an agent that has already read a large number of images has roughly a 30% chance of dying outright when given another heavy job, reporting "input too long".

This runs directly against another common misconception: a QC agent being told to "append while checking" to a file is not a suggestion, it is a hard requirement. In one film, a QC agent held everything until the very end before writing to disk, ran for an hour with zero output and stopped replying, so it could only be TaskStop'd and reassigned. The reason is simple: if it gets killed midway, all the conclusions accumulated so far are lost.

4.3 Concurrency Cap: Panes Are Shared Across the Whole Machine

This is the most counter-intuitive rule. The author hit it on film three: the pane cap was hit earlier than last time, with 14 other sessions open simultaneously, and dispatching the 5th agent gave respawn pane failed: fork failed: Device not configured.

The fix is to dispatch in waves of 4, waiting for one wave to complete and release before dispatching the next. Before dispatching, run ListAgents to check machine-wide usage and reserve 1 to 2 panes for the later QC and fix rounds.

This rule is the same in both Claude Code and Codex. The author specifically wrote a "dispatch and watchdog" section at the end of the prompt template: TaskStop finished agents promptly to release their panes, SendMessage once to agents killed by API errors, and TaskStop and reassign any agent with zero output for 10 minutes (when reassigning, explicitly tell it to "reuse the half-finished work on disk and only complete the unfinished part"). Check the mtime of each group's index.ts and BUILD_NOTES every 30 to 40 minutes.

4.4 Do Not Copy an Agent's Self-Assessment Verbatim

The author spot-checked one group's self-assessment: "the middle years are blurry and unreadable" — the actual rendered frames were sharp and readable, and that group itself admitted in its own retrospective that the self-assessment was too optimistic.

But his conclusion is not "agents lie". It is saying both things together: reports should be spot-checked, but don't jump to the conclusion that the agent was wrong — first look at the full evidence. Another case he investigated turned out to be his own misreading; the report was actually correct.

4.5 Build Groups Will Find Errors in the Storyboard Itself

This is one of the assets the author values most. The three most valuable improvements in film three all came from build groups: a contradiction between the value-bar formula and the on-screen annotation, a fact-compliance hole in the year dial, and the proactive departure from not giving millisecond values for counting.

His handling method is: adjudicate each issue in one sentence, then promote the ruling into a general rule for the whole film written back into the storyboard, rather than merely approving that one isolated change.

There is a matching hard requirement: reasonable deviations by build groups (swapping sample text, adding the Chinese full name, changing topology) are allowed as long as they have a source.

4.6 The Main Session Should Do Its Own Static Checks

The author is not satisfied with relying on QC alone. He keeps three checks of his own that can run without rendering: frame-coverage static analysis (gaps and overlaps in frame ranges), reconciliation of source literals against the fact list, and source-level counting of the glitch whitelist.

These three take only a few seconds and catch exactly the problems QC cannot find from pixels. In film four, source reconciliation caught a live counter in one shot: the screen showed "this second +2405" while small grey text right below read "tens of billions per day" — the two differ by a factor of 30, and all four QC agents missed it.

5. Summary: The Core Theses of This Project

Having read the whole protocol through, I summarize its views into seven points.

Thesis One: The Quality Bottleneck in AI Creation Is Not Generation Ability, but Specification

The output quality of every agent in this project depends heavily on how dense the specification is. The eleven documents under reference/, plus a hundred-odd components and functions in the templates — the actual amount of code is not large; the spec is thicker than the code.

Compare this with what lessons.md records: the initial skill had discipline items like safe areas, whitelists, exit-to-zero, and beats. The new film did better than the sample film on those items, but "how big to draw it, who glows" was never written down, so the new film came out small and dim. What isn't in the spec, agents will not think of on their own.

Thesis Two: Determinism and Editability Matter More Than a Stunning Image

Section 2.2 already expanded on this. The core is: because the picture is code, it can be statically analyzed, a single frame can be fixed precisely, and it can be traced to its source. Those three together are worth far more than "this frame looks great".

A direct corollary: do not use a generative model for this job.

Thesis Three: Constraints Must Be Written Down Explicitly — Do Not Expect an Agent to Grasp Them

"One running example across the whole film", "one hero element per shot", "at most one glitch per shot" — these are not suggestions, they are hard rules, and they have to be machine-checkable.

That is exactly what selfcheck.py exists for: it turns "glitch whitelist" from a slogan into a counting reconciliation. The whitelist has 23 entries, and the script must find exactly 23 hits — one more or one fewer is a problem.

The author gives a counter-example: if the word "glitch" appears in only one cell of the storyboard, the build agent will add glitch effects to all the text, and the finished film came out with 102 instances, which the user rejected outright. It was later changed to "at most 1 glitch per shot, only on that shot's key term", and only passed at 21.

Thesis Four: Narrative Quality Depends on Whether There Is a Through-Line, Not on Information Volume

Section 2 of narration-guidance.md and the retrospective on film four are two sides of the same coin. The first version of film four had 48 sentences written in the order of the reference book's subsections, and the user's first reaction was "too rigid and boring"; the version rewritten independently according to the writing principles scored 8.2 versus 4.3 in blind review.

The root cause is not prose quality, it is the absence of a through-line. If chapters can be reordered freely without loss, then there is no through-line.

There is a practice worth learning here: the author split "how to write so it is not boring" out of the "storyboard spec" and made it a separate narration-guidance.md, and made it mandatory reading at stage 2 in SKILL.md. narration-storyboard.md no longer prescribes a fixed chapter structure; it keeps only format, budget, and the picture interface, and the left column of the shot pattern table was changed to a topic-independent "visual relationship type".

Specifications should be placed at the right level of abstraction. Narrative principles are general; hanging them under a template tied to a specific topic gets them treated as part of the template.

Thesis Five: Finalize the Script Before Voiceover, Because Frame Numbers Get Hardcoded

This is the most counter-intuitive engineering decision in the entire pipeline, and it is the design basis for the four checkpoints.

Once the voiceover is final, frame numbers are written into the code of every shot. Changing one character = re-aligning the whole film = re-running every build group. So the author places checkpoint 2 (narration script final) before the voiceover, and says it very directly in the README: this is the cheapest intervention point in the entire flow.

Put differently, the first and second checkpoints are worth more than the third and fourth. The first (duration and language) determines the number of sentences, shots, and build groups — that is, the scale of the whole pipeline. The second (script finalized) determines how much has to be re-run if something is wrong.

Thesis Six: Quantitative Criteria Must Distinguish "Group Level" from "Finished Film"

The lesson left by film four: group-level motion_check was 48/48 passing, while the finished-film re-measurement found 11 shots over the limit.

Low-resolution rendering reads loose. The author's fix is to change group-level rendering to 0.5x scale plus JPEG q80, and to have the --frames mode emit one more column, "number of changed pixels at full resolution within the longest static segment", used to distinguish truly static (<800) from small-area motion (800–2500).

There is an even finer point: the fix for small-area motion is to increase amplitude, not to add elements. The motion element should be brighter, larger, and denser, with the hero element itself breathing ±2% over 30 frames, rather than piling on more small icons.

This distinction is critical. "Adding floating, drifting, or breathing to a static object" is explicitly forbidden; the author's reasoning is: the motion must be the action of the verb itself, and a shot with no verb action is better off staying still — a static stretch of ≤3 seconds is not a defect.

Thesis Seven: After Teaching the Agent, You Also Have to Teach It How It Will Be Judged

This is, I think, the most easily overlooked and most valuable point.

The author was not satisfied with "having the agent write code". He wrote the agents criteria, wrote quantitative scripts, wrote a final-check checklist, and wrote seemingly mechanical requirements like "every shot must produce at least one line of conclusion (write OK too)".

There is even one about counter-examples: examples/contrast/ contains 6 groups of counter-example frames, and before starting, the build agent must first use Read to look at contrast_sheet.jpg and at least 6 ref_*.jpg images to establish a yardstick.

This is turning "taste" into a "transferable reference". Taste cannot be written into a prompt, but you can hand over a set of contrast frames.

6. Design Philosophy Deconstructed

Gathering up the principles scattered across the project, its design philosophy comes down to roughly these seven.

6.1 Color Is Semantics

Every color in the palette carries a fixed meaning; not one of them was included just because it "looked nice":

Color	Value	Semantics
PURPLE	#6630F8	Current focus / active / brand
ORANGE / CORAL	#F05F41	Metric numbers, warnings, "the other side", query points
RED_DEEP	#EC081F	Deep-red warning blocks (hallucination, unreliable)
GREEN	#8FF740	Green checkmark (correct)
GREY family	#A0A0A1 and up	Non-focus text, grey blocks, gridlines

The rule is "at most one large purple focus area per frame". Color here is not an aesthetic question but an information question.

6.2 Light Goes Only to the Current Hero

The hero element always carries light (GLOW_PURPLE two-layer purple glow, or a HaloRing underfoot, or a large-text purple hard drop shadow 6px 6px 0 PURPLE); supporting elements do not glow.

Light has three levels: white bloom (structural lines, always on) < purple glow (hero always lit + current focus) < white flash (events, 3–6 frames). Only these three are used in the whole film, and light uses only purple, orange, and red.

There are also several fine-grained rules: the hero's light breathes ±15% over a 30-frame cycle; when focus transfers, the previous light dies within 8 frames; on exit the light goes out first (6 frames) and only then does the whole thing fade out — no hard cut while still fully lit.

6.3 Three Size Tiers, No Fourth

Hero ≥170px, or large text ≥96px with a full row width ≥300px; supporting elements 60–110px; labels and captions 22–30px. At most 4 supporting elements, at most 6 labels.

The value of the constraint "no fourth size beyond the three tiers" is that it automatically eliminates endless micro-tuning of the form "should this icon be a little bigger?".

The matching criterion is the empty frame: a maximum object height in the content area of <110px sustained for >45 frames is a moderate defect; <80px sustained for >45 frames is a severe one.

6.4 The Light Sweep Is the Most Expensive Move — At Most Twice in the Whole Film

The entrance choreography of three rounds of purple sweeping light + stage light + ghost outlines is the most expensive visual effect in the film, and the author sets the budget at ≤2 instances: one is mandatory for the first appearance of the core concept, and the second is optional for the callback at the end.

The reason is user feedback. Film five used 8 three-round light sweeps across 47 shots, and users watching the finished film said it was "too frequent". The sample film used it only once across 44 shots.

The storyboard therefore has a separate "light-sweep whitelist" column; any shot not on the list must not use LightSweep / StageLine / GhostText. selfcheck.py counts per file, and the final check verifies frame by frame.

This is a design worth learning: rather than saying "use fewer shiny effects" in the prompt (models don't understand that), give it a hard quota and a whitelist.

6.5 Sustained Verb Action + Settle-and-Hold

This is the latest-formed and also most important kinematic rule in the project; it addresses two opposite failure modes:

"Arrive and freeze": elements come in on the beat and then just sit waiting for the next beat, with only a glow breathing. After the fourth film quantified this: 4/6 shots had 42% to 72% static frames, with a longest static stretch of 2.8 seconds.
"Settle and cut": overcorrected while fixing "no static longer than 30 frames" — across 47 shots there were 34 push-ins and 48 sentences marked "sustained", with the final-beat element entering the last-8-frames exit the moment it landed. The user's own words were: "everything animates just as it lands, and then it immediately cuts to the next shot — there is almost no dwell time".

Rule one is sustained: for the verb a subtitle block is describing, there must be an action on screen that continues to the next beat; after entering, an element must not be completely static for more than 3 seconds (90 frames); but do not add floating, drifting, or breathing to a static object just to hit a metric.

Rule two is hold: after the final-beat element of a shot lands, it needs a stable period of 30 to 45 frames (1 to 1.5 seconds) before exiting. During the stable period, no new elements, no camera moves, no HUD swaps; verb actions already in progress may continue. Camera moves do not enter the final beat.

Where does the time come from? The user's ruling: it is acceptable for the finished film to be 5% to 8% longer than the pure voiceover in exchange for dwell time. Pauses go only at paragraph ends, not after every sentence.

The author delivers this set of rules together with its quantification script motion_check.py in the docs, rather than merely writing them into the spec.

6.6 Transitions Must Specify Both Sides

The author stepped into a very typical trap. If the storyboard only says "hard cut", each side will interpret it as "I don't move, you enter only on the beat frame", producing 6 to 8 frames of empty frame at the group boundary — 5 occurrences in one film.

So the prescribed wording is: "A's final 8 frames fade out to zero + a slight tilt down; B's first frame brings in the first batch of elements with SoftIn".

The matching rule is that handoff takes priority over clearing the frame: a short sentence that finishes a beat is folded into the previous shot, with a 16-frame handoff shift making room for it, instead of clearing the frame and redrawing for it.

Chapter boundaries are stricter: the first shot of a chapter must carry over the hero element or symbol from the previous chapter's last shot (same component, same parameters, possibly scaled and repositioned), and the narration must both carry over and set up. The author's counter-examples are "starting the chapter from zero" and "merely announcing the chapter"; the difference is: don't announce, do carry over and set up.

6.7 Fact Compliance Is an Aesthetic Question

This one is the most interesting. On the surface it is a QC rule; in reality it is design philosophy.

The author's criterion is: every number that appears on screen must be traceable to a source. The direct design consequences are:

Intermediate values in count-up animations are also "numbers that go on screen". A linear year count from 1995→1998 makes 1995, 1996, and 1997 clearly readable for 4 to 6 frames; milliseconds 0→120 flashes out "37 ms" and "88 ms". None of these are in the fact list, so either make them unreadable or don't do the count-up at all.
Making the years unreadable has to be brutal: blur 6.3→1.3px still leaves the middle years clearly readable; at 12→2px the second-to-last year is still discernible for about 2 frames; finally 12→9px throughout plus settling the settled frame back to 0 is what makes it clean. The author packaged this as the YearRoll component in the template.
Sample data (model names, similarity scores, amounts) is marked as "illustrative values" in the delivery notes.

This is not making things hard for the author himself; it is protecting the audience. A video cannot be clicked to reach its source, cannot be checked; the audience can only take your word for it.

7. Limitations, Objections, and What to Watch Next

7.1 Three Real-World Limitations I Need to State First

First, it is not a "give it a topic, get a film" product. It needs a human (or rather, an agent main session) to make decisions at four points: duration and language, narration script final, voiceover engine, and the first-30-seconds sample. Not one of the four checkpoints can be skipped, and the author has no intention of skipping them.

From the standpoint of "give you an input and you get a finished film", this is still a long way from a product. But from the standpoint of "let an agent complete a film on its own", it has already gone very far.

Second, the cost is not low. The sample-film tier runs 8 build groups in parallel for 40 minutes, plus two QC rounds of 60 to 90 minutes, for roughly 2 hours end to end and 2GB of disk from the start. And that is on the assumption that you are already comfortable with Remotion.

Third, licensing is a hurdle. PolyForm Noncommercial 1.0.0: free for non-commercial use, and commercial use requires obtaining the author's authorization in advance. For explainers, tutorials, and personal projects that is fine; if you want to use it in a commercial product you have to negotiate first.

7.2 The Two Questions I Think Are Most Worth Pushing On

Question one: can this method be reproduced on a machine without the author present?

The tone of the whole repository is "one person made film after film, writing each pitfall back into lessons.md". The completeness of the protocol depends heavily on those pitfall records, and they were accumulated over four days between 2026-09-07 and 09-10.

The advantage of this kind of "experience-sedimentation" document is that every entry is backed by real rework, so it carries weight. The risk is that it has only been verified on the author's machine, with the author's Claude Code configuration, and the author's pane limit. The README says "Linux should work, Windows is untested", and it has been run on a Raspberry Pi, which is already an honest disclosure — but it is still not "anyone can run it on any machine".

Question two: what is the actual bottleneck of this pipeline?

The author put all of his attention on "making the picture better" — subject size, light, set pieces, light-sweep quota, sustained verb action, settle-and-hold; all of it visual. But in lessons.md he himself admits something more interesting:

Style transmission (2026-09-08 retrospective): the skill wrote the prohibitions but not the aesthetic drivers…… but "how big to draw it, who glows, how to arrange the set pieces" lives only in the head of whoever makes the sample film.

In other words, he spent a lot of space treating the symptom of "AI renders badly", and has been at it for two years. But looking at the overall structure of lessons.md, what is genuinely scarce is not the aesthetic rules but the methodology for decomposing one person's aesthetic judgment into a transferable, checkable, iterable form. This project is currently one successful attempt in that direction, not a mature general-purpose methodology.

One piece of corroborating evidence is his own retrospective conclusion: "the gap isn't in 'how much it moves'; don't go fixing it by adding more motion effects." The value of that sentence is that it is a negative judgment — it eliminates one direction rather than pointing to a direction. The genuinely hard part is finding where to fix.

7.3 What to Expect Next

Vertical video. The README explicitly says 9:16 is not supported; the templates and all safe-area rules assume a 1280×720 landscape canvas. Short-video platforms are basically all vertical, so this is the most obvious gap.
More languages. Only Chinese and English are supported today, each with its own speech-rate model, subtitle budget, and default voice. The architecture of the lang field leaves room for extension.
Higher-quality TTS. The current path is "bring your own TTS" — the user generates the finished wav themselves and fills in the timeline by hand. The author explicitly says the default edge-tts and kokoro are "good enough but not the best". This means the whole pipeline is open to techniques like voice cloning and forced alignment.
Expansion of the counter-example library. examples/contrast/ currently has only 6 groups, and all the positive examples come from the same film (the sample). A few more positive examples across different topics would help transmit the aesthetic standard.

7.4 The Design Decision Most Worth Learning From

If I could take only one thing away from this project, I would choose this:

Turn "taste" into the three-piece set of "reference + criteria + counter".

Reference: the 6 groups of positive/negative frames in examples/contrast/contrast_sheet.jpg, which the agent must look at before starting.
Criteria: the three size tiers, light ownership, empty-frame thresholds, and the light-sweep quota in composition-and-light.md.
Counter: selfcheck.py counts the glitch whitelist, frame_metrics.py measures subject height and glow, motion_check.py measures static duration.

With only the first two, the agent will understand but will drift. Add the third, and the drift gets caught immediately.

The author gave a very practical observation at the end of film four: when one group of agents reported "the middle years are blurry and unreadable", the actual rendered frames were sharp and readable. He did not treat this as agents being unreliable; instead he added "statically extract every literal from the source that would go on screen, and reconcile it against the fact list" as a check step.

This is what a continuously improving system should look like: every failure becomes a new check item, rather than a one-off complaint.

8. One-Sentence Summary

anything2explainer turns "have AI make an explainer video" from a prompt problem into an engineering problem.

It does not generate pixels, it generates deterministic code; it does not rely on the model to grasp aesthetics, it transmits aesthetics through references, criteria, and counters; it does not expect the agent to get it right the first time, it writes every rework into lessons.md as the next film's check items.

For someone who wants to make technical content, the most practical part of this repository is probably not those 9 stages, but what has accumulated across the 11 reference/ documents: how big the subject should be drawn, who the light should fall on, how to arrange the set pieces, how many times a light sweep may be used, where the pause belongs, why both "arrive and freeze" and "settle and cut" are defects, and how to use three scripts that finish in seconds to check whether the agent actually did any of it.