/sglang-explainer-video

name: sglang-explainer-video
description: Turn an SGLang PR (number or URL) or a technical article (Markdown path) into a Chinese explainer video that fully explains every algorithm and code change (length follows the material, no time cap) — natural edge-tts narration, word-synced bilingual 中文/English captions, the unified orange "SGLang PR 讲解 / SGLang 技术解读" cover, SGLang-brand visuals — built on HyperFrames' pr-to-video pipeline and delivered to ~/Desktop. Use when the user sends an sgl-project/sglang PR number or link, or an article file, and asks for a video (做个视频, 讲解视频, PR 视频, 文章转视频).

SGLang explainer video

Input: `sglang PR <N>` (or a github.com/sgl-project/sglang/pull/N URL), or a Markdown article path. Output: `~/Desktop/SGLang_PR<N>_讲解_中英字幕.mp4` (article: `SGLang_<slug>_技术解读_中英字幕.mp4`) plus a still `…_封面.png` and a Bilibili cover `…_封面_B站.png`, rendered 1920×1080 with a 中文 narration and bilingual captions.

This skill drives HyperFrames' **pr-to-video** workflow (heygen-com/hyperframes, pinned) with a fixed house style and several fixes that make it work for Chinese. Read `references/house-style.md` before writing any script — it holds the rules the user already corrected once (terms, captions, cover, credits, PR status).

Core principle: understand it fully, explain all of it

The video exists so a viewer who has not read the PR / article **understands every algorithm and every meaningful code change** in it. That decides everything else:

• **No target length.** Length follows the material: a one-line docs PR may need ~1 min; a multi-file kernel

or scheduler PR, or a long article, may need 5–10+ min. Never cut a mechanism, code path, edge case, number or caveat to make the film shorter — add frames instead. Keep each frame to one idea (≲ 60 汉字, ~11 s) so visuals keep up; the *number* of frames is unbounded.

• **Understand before you script.** Read all of the source (Step 2) and write `capture/understanding.md`

first; every item in it must map to at least one frame.

• **Code is the spine, not a footnote.** Open with the value (what the change fixes / speeds up), then walk

through the algorithm and every changed code path in a sensible order, with a worked example where it helps. This overrides pr-to-video's `story-design.md` where it says otherwise (its "Whole-film target ≤ ~3 min", "feature 2–4 real diff hunks", "implementation is the footnote"): feature **every hunk that carries logic** (group pure renames / formatting / test boilerplate into one frame), split long hunks across frames (≤ 12 lines each), and explain why each change is needed, not just what it is.

0. Setup (start of every session)

bash <this-skill>/scripts/setup_env.sh      # first run ~2 min; afterwards seconds (idempotent)
source ~/.cache/sglang-explainer-video/env.sh

Re-run it at the start of each session: `env.sh` records this skill's install path (`$SEV_SKILL`, `$HF_MEDIA_ENGINE`), so it must point at the copy you are using now.

It needs Node ≥ 22 (`brew install node@22`), `ffmpeg`/`ffprobe`, git, curl and Chrome. It creates a venv (edge-tts, fonttools, and mlx-whisper on Apple Silicon for `pron_check.py`), a pinned HyperFrames checkout with `patches/hyperframes-captions-cjk-bilingual.patch` applied, the Noto Sans/Serif SC fonts, and `env.sh` (`$SKILL_DIR` = pr-to-video, `hf` = pinned HyperFrames CLI wrapper, `$HF_MEDIA_ENGINE` = our edge-tts engine, `$SEV_SKILL`, `$SEV_PY`). Nothing is installed globally: always run the CLI as `hf …`, never `npx hyperframes init` without the env (init would install skills into `~/.claude/skills`).

Every command below assumes `source ~/.cache/sglang-explainer-video/env.sh` and `P=<project dir>`.

1. Project + brief

P=$SEV_WS/projects/sglang-pr-<N>            # article: $SEV_WS/projects/sglang-article-<slug>
hf init "$P" --non-interactive --example=blank --skill=pr-to-video

Write `$P/BRIEF.md` (template in `references/house-style.md` §Brief). Run **autonomous** (`flow: automation`, `storyboard: no`): do not stop for plan/sketch approval; the only questions worth asking are real choices (voice change) — otherwise follow the house style. Never ask about length: it follows the material.

2. Ingest the source

PR mode — always the **full URL** (`owner/repo#N` fails outside a git checkout):

(cd $P && node $SKILL_DIR/scripts/fetch-pr.mjs --pr https://github.com/sgl-project/sglang/pull/<N> --out-dir ./capture \
  && node $SKILL_DIR/scripts/ingest.mjs --pr-json ./capture/pr.json --diff ./capture/diff.patch --out-dir ./capture/extracted \
  && node $SKILL_DIR/scripts/fetch-people-avatars.mjs --people ./capture/extracted/people.json)

Article mode — copy the article to `$P/capture/extracted/visible-text.txt`, write a minimal `capture/extracted/tokens.json` (`{"title": "...", "colors": [], "fonts": []}`), and download the article's own figures into `$P/assets/article/fig<i>.<ext>` (they are the author's images; they become real assets on frames).

**Read everything before writing anything.** `capture/extracted/visible-text.txt` is budget-truncated, so it is not enough on its own:

• PR mode: the PR body, the **full** `capture/diff.patch`, review comments that changed the design

(`gh pr view <URL> --comments`), and every touched function **in full at the PR head** (`gh api "repos/sgl-project/sglang/contents/<path>?ref=<headRefOid>" --jq .content | base64 -d`) so you can explain the code around each hunk, not just the hunk. Follow calls into helpers when the change depends on them.

• Article mode: the whole article, every code block and figure, and any PR / source file it links to that the

argument depends on.

Then write `$P/capture/understanding.md`: the problem; the algorithm step by step; every changed code path (`file:function` → what changed and why); the numbers with their conditions (hardware, model, workload); the caveats the author states. This is the coverage checklist for Step 3.

T