HyperFrames pr-to-video：将 GitHub Pull Request 一键转化为代码变更讲解视频-创锋一号

HyperFrames pr-to-video：将 GitHub Pull Request 一键转化为代码变更讲解视频

【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes

导读：HyperFrames 是"Write HTML. Render video. Built for agents."的视频框架，其pr-to-video路由专为 GitHub Pull Request 设计——输入一个 PR 引用（URL、owner/repo#N或 "this PR"），输出一段以 diff、before/after、文件树和影响场景为骨架的 changelog / feature-reveal / fix-explainer / refactor-walkthrough 讲解视频，硬上限约 3 分钟。读完本文，你将掌握该路由的完整工作流（Step 0–6）、PR 体量→时长映射表、叙事设计方法与code-*动画块词汇，以及底层脚本（fetch-pr / ingest）的实现原理。

一、路由定位：输入、输出与触发词

pr-to-video是 HyperFrames 意图层（intent layer）路由表中的第七优先路由（见 skills/hyperframes/SKILL.md），核心契约记录在 skills/hyperframes/references/routes/pr-to-video.md：

输入：GitHub PR URL、owner/repo#N、或已检出仓库中的 "this PR"，通过gh读取；它不是网站截图请求。
输出：带 diff、before/after、文件树与影响场景的 changelog、feature reveal、fix explainer 或 refactor walkthrough 视频；硬上限约 3 分钟，时长跟随变更体量。
触发词："make a video about this PR"、"turn PR #1187 into a changelog video"、"release-notes video from this pull request"。

该路由与product-launch-video（网站/产品推广）和faceless-explainer（无 PR 的主题讲解）的关键区别：输入是代码变更而非网站——没有 capture 步骤，也没有真实素材（贡献者头像除外）。意图不明确时统一回退到/hyperframes入口，由 skills/hyperframes/references/intent-interview.md 负责路由决策，最终把锁定的 brief 写入BRIEF.md，后续流程只读该文件。

二、Interview 阶段：把 PR 体量翻译成时长

路由文档定义了访谈阶段（Interview）必须收集的要素：

要素	说明
PR 引用	URL、`owner/repo#N`或 "this PR"
角度 (angle)	changelog / feature-reveal / fix-explainer / refactor-walkthrough，优先推荐 PR 自身暗示的那个
受众 (audience)	开发者（默认）、混合技术人群、非技术干系人
时长 (length)	由下方体量表推导
目的地 (destination)	代码讲解默认 16:9

时长必须来自 PR 的变更体量，而不是拍脑袋——先只读地 peek 一次（工作流的 Step 1 仍会做完整的确定性抓取）：

gh pr view <PR_REF> --json title,additions,deletions,changedFiles

以additions + deletions为基准（changedFiles向上微调）选定档位，并在 pitch 中说明依据：

PR 变更体量	推荐时长
trivial（≲ 50 行变更）	~20–40s
focused（~50–200 行）	~40–70s
substantial（~200–600 行）	~70–110s
large（≳ 600 行，或 25+ 文件）	~110–180s

用一句话陈述依据，例如 "~40s — small change, +44/−13 across 12 files"。档位是 diff 能支撑的故事上限，绝不是需要填满的下限：一个一句话能讲完的故事，无论档位如何都建议 30–90s 内收尾（档位区间可以作为一个"非推荐的完整 walkthrough 选项"出现）。

Interview 阶段还包括pitch round（角度与开场钩子——diff 修正事实，而不是叙事）与run-shape（协作/自主两种运行形态）。相应的详细访谈模板见 skills/hyperframes/references/pitch-round.md 与 skills/hyperframes/references/intent-interview.md。

三、工作流总览：Step 0–6

完整工作流定义在 skills/pr-to-video/SKILL.md，阶段与产物一一对应：

步骤	目标	关键产物
Step 0 Setup	确认 brief（含 PR 引用）、初始化项目	`hyperframes.json`、`BRIEF.md`
Step 1 Ingest（无 capture）	抓取 PR 事实并入项目	`capture/pr.json`+`capture/diff.patch`→`capture/extracted/{tokens.json, visible-text.txt, people.json}`+`assets/<login>.png`
Step 2 Design System	采用 code-editorial 帧预设	`frame.md`+`.hyperframes/caption-skin.html`
Step 3 Storyboard & Script	把 PR 变成逐帧讲解计划	`STORYBOARD.md`（+ 需要旁白时的`SCRIPT.md`）
Step 3.1 Audio	生成旁白、词级时间戳、BGM 与音频元数据	`audio_meta.json`
Step 4 Frame Visual Design	给每帧补充视觉方向与运动选择	富化的`STORYBOARD.md`
Step 5 Build Frames	逐帧构建 HTML 合成并装配可播放视频	`compositions/frames/NN-*.html`+`index.html`
Step 6 Finalize	校验、审核、渲染	`renders/video.mp4`

三个用户门控步骤是 Step 0、Step 3 与 Step 6；Step 5 通过有界 worker 池派发。风格在 Step 2 固定为code-editorial（温暖的编辑风格：海军蓝代码面、稀缺珊瑚色强调），从不询问用户。

Step 0：Setup——先确认 brief，再建项目

项目目录解析用project-dir.mjs，优先保留用户指定目录，否则使用解析器输出的持久化外部缓存位置；绝不在调用方仓库里创建videos/。
init前运行preflight.mjs能力预检；若已安装 CLI 无法运行本技能所需的校验命令，先停止并按升级指引处理，而不是浪费上下文。
初始化命令：npx hyperframes init "$PROJECT_DIR" --non-interactive --example=blank --skill=pr-to-video，项目 basename 取自 PR（如acme-sdk-pr-1842），绝不用工作区名或时间戳。
init 之后立即写BRIEF.md（绝不能在 init 之前，init 拒绝非空目录），形状遵循 brief-contract；随后展示npx hyperframes auth status的签名状态（决定 TTS/BGM 走 HeyGen 还是本地引擎）。

Step 1：Ingest——没有 capture，用`gh`确定性抓取

这是该路由与"捕获型"工作流最本质的区别。fetch-pr.mjs取代裸gh pr view > capture/pr.json，其实现（skills/pr-to-video/scripts/fetch-pr.mjs）有三个关键设计：

大 PR 文件列表补全：gh pr view --json files在约 100 个文件处截断，脚本改用分页的gh api --paginate repos/{owner}/{repo}/pulls/{number}/files（64MB 缓冲），按页--jq输出 NDJSON 补全pr.files，并同步修正changedFiles。
只写两个文件，无 scratch 目录：capture/pr.json+capture/diff.patch，中间数据全部驻留内存，避免污染工作区且保证确定性；gh的 auth / not-found / private 错误会以gh自身的 stderr 退出 1，编排者随即停止，绝不虚构 PR 内容。
MERGED PR 的 best-effort 版本解析（shipped_version+version_source）：端卡/CTA（"upgrade to vN"）需要一个真实版本，而 PR 本身不携带版本。脚本先找 merge 之后第一个非 draft release 的 tag；失败则回退到默认分支package.json的 version 并标记unreleased；再失败则置 null（技能随后回退到仅引用仓库 URL）。

随后的ingest.mjs（skills/pr-to-video/scripts/ingest.mjs）是纯离线转换，产出合成 capture 包：

tokens.json：colors:[]/fonts:[]→ 保留 code-editorial 原生调色板（PR 没有品牌 token）；
visible-text.txt：叙事 SOURCE——由标题 + meta（base ← head · +N/−M across F files）+ people + body + commits + 变更文件 +预算受限的代表性 diff hunks组装的可读 brief；body 截断 2600 字符、diff 截断 4800 字符、每 hunk 上限 22 行（renderHunk会折叠连续上下文为⋯标记）、commits 上限 12 条、文件列表上限 40 条，噪声路径（lockfile / dist / min / map 等）在 hunk 选择中被降权；
people.json：贡献者（PR author / commit authors / reviewers / commenters / assignees）经 bot 去重过滤——isBot用[bot]后缀 + 一个覆盖 dependabot、github-actions、codecov、renovate、snyk-bot 等 30 个常见 CI 机器人的 denylist；关键区分是PRauthor只是开 PR 的人，不一定是写代码的人，因此commits[].authors[]的提交作者被单独统计commitCount并按角色排序，供 credits close 使用。

头像下载fetch-people-avatars.mjs是唯一网络步骤，best-effort 恒退出 0——缺失头像只是意味着没有作者 credits close。Step 1 的 gate 要求你能用一句话讲清这个 PR 改了什么。

Step 2：Design System——code-editorial 固定预设

node <SKILL_DIR>/scripts/build-frame.mjs --preset code-editorial --hyperframes .

脚本把 code-editorial 预设的FRAME.md复制为frame.md、复制 caption skin 到.hyperframes/caption-skin.html，并自我校验（映射断裂时退出 1）。PR 没有品牌 token，因此保留预设自身的完整设计，不做任何手改。

Step 3：Storyboard & Script——叙事设计而非朗读 diff

核心规则一句话：diff 是一串编辑，视频是一次被引导的理解行为。绝不逐文件朗读 diff、绝不朗读 PR description——这是最常见的失败模式。场景顺序来自叙事设计，而不是 diff 的文件顺序或 commit 列表；"价值先于证据"——观众可见的收益（这个变更解锁/修复/加速了什么）必须在第二个 beat 落地，diff 与机制是它的证据，绝不是开场。

具体叙事方法见 skills/pr-to-video/references/story-design.md，后文第四节展开。

Step 3.1：Audio——旁白、词级时间戳与 BGM

默认音色Marcia（HeyGen）/am_michael（Kokoro）；用户点名音色/性别/语气时用--voice <id>传入，否则"男性声音"这类请求会被静默忽略。
命令：node <SKILL_DIR>/scripts/audio.mjs --script ./SCRIPT.md --storyboard ./STORYBOARD.md --hyperframes . --out ./audio_meta.json --voice <voice-id> &（后台运行，然后继续 Step 4）。
全静默的标准标记：STORYBOARD.md顶部 YAML 的music: none且没有SCRIPT.md——audio.mjs识别后什么都不生成并清除过期的audio_meta.json（assemble把缺失的audio_meta.json当作静默）。music: none但有旁白则只关 BGM。拼写必须精确，不要自创标记。

Step 4：Frame Visual Design——时间编码的镜头序列

方法主体在 skills/pr-to-video/references/visual-design.md。核心单元是按旁白编排的时间编码镜头序列（time-coded shot sequence）：每个 Scene 窗口声明"屏幕上有什么、什么在动、坐在哪里（inline 布局）"，任何东西都不能在旁白提到它之前出现——这是反 PowerPoint 的核心机制。反模式是 front-loading：在开头 ~25% 把整个画面堆上去然后冻住。

每个代码帧的scene里必须指名 hunk 与code-*块（如 "therequest()retry block, ~6 lines,code-diff"），并附一个不超过 12 行的### Source excerptfenced diff 块——worker 被禁止重新打开完整 diff。运动词表与规则 id 见 skills/pr-to-video/references/motion-language.md。

Step 5：Build Frames——有界派发与装配

先等 Step 3.1 音频完成，然后audio.mjs sync-durations（真实旁白时长优先，静默帧保留估算，绝不手改同步后的时长）与fetch-sfx。
预先安装STORYBOARD 命名的全部 registry 块（npx hyperframes add <block-name>），避免并行 worker 竞争 registry。
frame-packets.mjs构建有界 packet（代码帧缺少### Source excerpt直接硬失败，并硬性限制 packet 字节），写_role.md；最多派发 3 个 worker，每个 worker 只读自己的 packet 与frame.md，绝不打开完整 STORYBOARD、diff.patch 或 visible-text.txt。
失败帧只重派该帧（最多一次重试），必须附上具体的 validator/lint 发现。
全出血背景挂在class="clip"层上，绝不在#root——背景设在#root/data-composition-id上会被帧窗口裁剪，深色内容会落到黑色宿主body上不可见。
背景装配：captions.mjs build（用.hyperframes/caption-skin.html注入 token）与assemble-index.mjs（把头像从assets/幂等暂存）。

Step 6：Finalize——校验、审核、渲染

node <SKILL_DIR>/scripts/transitions.mjs inject --storyboard ./STORYBOARD.md --hyperframes . node <SKILL_DIR>/scripts/transitions.mjs verify --storyboard ./STORYBOARD.md --index ./index.html npx hyperframes lint npx hyperframes check npx hyperframes snapshot --at <frame-midpoints> # → snapshots/contact-sheet.jpg

命令失败时浮出 stderr 并停止，不要堆叠恢复命令；对compositions/frames/NN-*.html做最小安全修改后重跑失败项。
已知误报不要追：check可能报 caption 高亮词（#caption-word-*/.caption-line）约 1–4px 的text_box_overflow——caption pill 的line-height故意紧凑且无overflow:hidden，重字重字形的墨迹溢出到 pill 自身 padding，实际没有任何裁剪。不要加大 captionline-height（会让 pill 膨胀）。只有当text_box_overflow指向帧元素（#el-NN-*）才需要处理。
审核后渲染：npx hyperframes render --skill=pr-to-video --quality high --output renders/video.mp4；交付 MP4 + contact sheet + 帧 id（便于精确到单帧的修订）。预览npx hyperframes preview "$PROJECT_DIR" --background，收尾--stop只停本项目后台服务器，审核期间绝不拆除。

四、叙事设计：四个 PR 原型与 PR 原生帧类型

story-design.md把 PR 视频归为四种完整路径（可复合，arc写作"<outer> with <inner>"）：

原型	结构	适用
Changelog	hook 点名头条 → 2–4 个并列变更项 → ship/wrap	发布 PR、"vN 有什么新东西"
Feature-reveal	hook（用户语言的结果）→ impact（现在能做什么）→ change（命名）→ diff（新代码敲入）→ mechanism（动画演示）→ 回扣承诺	新增一个显著特性
Fix-explainer	problem（症状）→ mechanism（坏行为动画）→ diff（cause+fix 的 before→after）→ mechanism/impact（现在正常了）	bugfix PR，tension→turn→relief
Refactor-walkthrough	hook（smell/why）→ before_after → mechanism（结构解开，同输入同输出）→ evidence（行数/perf 数据）	重构、性能、清理、迁移

选型 tie-breaker：修 bug 的特性 → feature-reveal 带一个 fix body beat；需要小重构的 fix → fix-explainer（fix 是头条）。

PR 原生帧类型（type字段，叙述+节奏标签而非硬枚举，每种映射到 code-editorial 的处理方式与典型视觉）：

`type`	职责	典型视觉
`hook`	高杠杆开场 3–5s	Cover（或`code-3d-extrude`英雄代码时刻）
`problem`	PR 解决的 bug/smell/pain	`code-highlight`（聚光问题行）
`change`	命名变更/特性/PR 本身	Statement / Cover
`diff`	变更主体——before→after、hunk、新代码敲入	`code-diff`/`code-morph`/`code-typing`
`before_after`	旧形状 vs 新形状显式对比	`code-morph`/`code-diff`
`mechanism`	展示变更在运行时的行为（请求重试、缓存填充、串行→并行、竞态解决）	奶油底上的发明式 SVG/GSAP 图表；`flowchart`/`flowchart-vertical`/`data-chart`
`impact`	收益落地——现在能用什么	`number-lockup`
`evidence`	具体佐证——`+N/−M`、通过的测试、benchmark	`code-diff`红→绿 /`number-lockup`
`credits`	shipped-by close——变更背后的人	头像行（`assets/<login>.png`）
`cta`	收尾号召——pull it / upgrade / read the PR	珊瑚色 callout

正文节奏铁律：交替diff（展示变更的代码）与mechanism（展示变更的运行时行为），落在impact/evidence上。全 diff 的正文读起来像代码 show-and-tell；每个 PR 都有变更，所以至少存在一个diff/change帧，而多数 PR 也值得一个行为动画帧。

Hook 策略（选择其一，钩子说观众的结果语言，绝不报文件名/函数名/标识符）：惊人统计（"This PR deletes 1,200 lines."）、反直觉主张、痛点共鸣（"Every deploy, the same flaky timeout."）、概念宣告、before/after teaser、利害/后果、直接对话。

每帧字数预算——字数才是真正的度量：TTS 约2.2 词/秒，45 词的"7 秒"脚本实际要 20 秒。默认软目标 ≤19 词 / ≤9s；例外（最多 2 帧：主 diff 或因果链 change）≤26 词 / ≤12s；硬上限 >26 词必须裁剪或拆分；整片目标 ≤~400 词（甜区 30–90s / ≤~155 词）。估算公式duration ≈ ceil(word_count / 2.2)。静默帧合法且常见——diff 敲入、before→after morph、计数器滚动都可以静默，voiceover留空、不进SCRIPT.md。每行旁白写成离散 cue（"Three retries — then it backs off — then it gives up clean"），让 Step 5 能按词揭示画面。

五、code-* 动画块词汇：代码帧的现成中心件

skills/pr-to-video/references/code-vocabulary.md 定义了代码帧的两类"会动的画面"：代码（变更的行）与行为（变更在运行时做了什么）。安装方式统一为npx hyperframes add <block-name>（写入compositions/<block-name>.html），作为子合成以data-composition-src挂载进帧。每个块内联了引擎与一条被引擎按帧 seek 的暂停 GSAP 时间线，全部 1920×1080、确定性/seek-safe（无 CSS transition、无 rAF、种子随机——绝无Math.random/Date.now）。定制只改两个全局：window.__TOKENS（Shiki token 化的代码内容）与window.__BLOCK（效果与时间选择）。

块	行为	注意输入	PR beat
`code-diff`	编辑器窗内的 unified diff：删除行红色折叠、新增行绿色展开（6s）	恰好 2 个 states，引擎做 LCS diff	默认 PR 块，字面 add/remove
`code-morph`	一段代码变形为另一段，共享 token 滑行、退场淡出（7s）	2+ states；跨 state 复用 token`key`才滑行	重构/重命名/签名变更（连续性）
`code-typing`	逐字符打字机 + 滑行光标（5s）	单 state	新函数/文件"敲入屏幕"
`code-highlight`	蓝带扫过一行，其余变暗（5s）	`__BLOCK.line`0-based	聚光关键行
`code-scroll`	"镜头"滚动长文件定位目标行（6s）	`__BLOCK.line`1-based	在大文件里定位变更
`code-3d-extrude`	光照斜面的 3D 代码板旋转落位（8s，WebGL）	单 state + seed	英雄代码时刻（风格优先，不用于读 diff）
`code-particle-assemble`	GPU 粒子散射后飞回精确字形像素（8s，WebGL）	单 state + seed	戏剧性高潮揭示
`code-shader-dissolve`	代码从种子噪声中"编译成形"+ 边缘辉光（7s，WebGL）	单 state + seed	"编译通过/可以工作了"
`code-snippet-flight`	离散片段从侧边飞入组装成堆叠程序（6s）	`__TOKENS.flight.states`	"各模块拼装成特性"

三大坑：① 必须把块的内建节奏适配到帧的data-duration（code-typing按固定字符速度打字，长片段会超帧）；②code-diff/code-morph需要 ≥2 个 baked states，其余单 state；③ 行索引不统一（code-highlight0-based、code-scroll1-based）。另外这些块是全出血无 caption 安全带的，启用字幕时要把代码面板控制在顶部 ~83% 以内。

code-snippet-*家族是独立成品合成而非调色板：VS Code workbench 12 个主题与 Apple Terminal 12 个 profile，适合要"真实 IDE/终端"环境感时使用。

六、mechanism 帧：用动画证明行为，而不是只展示代码

机制帧是 PR 视频不显扁平的最重要解药。它不是code-*块，而是：发明的动画图表（SVG/HTML/GSAP，用 code-editorial 的原子：奶油底、发丝墨线的节点/边/泳道、一个珊瑚色激活标记）；或flowchart/flowchart-vertical/data-chartregistry 块。按变更触及的内容选择动画对象：

变更触及…	动画（行为，不是代码）	使用
重试/退避/韧性	请求生命周期：fire → 500 → 等待（延迟增长）→ retry → 200	发明 SVG/GSAP
缓存/记忆化	冷（慢，打 DB）vs 热（快，打缓存）两车道竞速	发明 SVG/GSAP
并发/并行	串行单车道重塑为并行车道	发明 /`flowchart`
竞态/顺序 bug	先坏流程（丢项、双写冲突）再修好流程	发明 SVG/GSAP
性能	两条时间线/柱竞速，新的先到	`data-chart`
重构/迁移	纠缠调用图解开成干净图；同输入→同输出	`flowchart`/ 发明
新端点/管道/状态	数据流过新路径；状态机逐步点亮	`flowchart-vertical`

与code-*块拥有自己的动画不同，图表的运动是你的：把 ≥3 个效果编排为入场（画节点/泳道）→ 发展（跑流程）→ 落位（解决态 + 一处珊瑚强调），绝不让它入场后冻结。diff 帧与 mechanism 帧互补——diff 是代码中的证明，mechanism 是运动中的证明。

七、Credits close：真实的人，真实的版本

每个 PR 视频都以credits帧收尾，点名真正的贡献者（skills/pr-to-video/references/story-design.md）：

PR author 只是开了 PR，不一定是写代码的人——常是队友提交了大部分 commit。credits 按commitCount优先 committer，再排 reviewers。
仅此帧设置asset_candidates（1–6 个assets/<login>.png，仅avatarFetched: true的 login）；正文保持纯代码，头像只出现在 close。
旁白念名字，绝不念 handle：people.json只为 gh 已命名的贡献者带name字段（author / commit authors / mergedBy），reviewers/commenters/assignees 只有裸 login——写 credits 前用gh api users/<login> --jq .name补全将上屏的 1–6 人的名字；GitHub 也没有公开名字时，屏上回退到 login，并从口播行中剔除该人。TTS 朗读裸@miguAng18947550是这套机制要避免的失败模式。

版本是唯一绝不允许编造的事实：cta（"upgrade to vN"）或 changelog（"what's new in vN"）需要真实版本，而 PR 不带版本——Step 1 为 MERGED PR 解析 best-effort 版本并写入visible-text.txt的Shipped in: <version> (<source>)行。Shipped in:存在就用该确切版本（version_source为unreleased时改口 "shipping in the next release"）；没有该行（未合并或解析失败）就只写仓库/PR URL，绝不猜测版本号。

八、视觉与运动：时间编码镜头序列 + 四条运动信条

视觉设计方法（skills/pr-to-video/references/visual-design.md）要求每个帧是一组按 VO 编排的时间窗口，窗口数 = 旁白 cue 数，揭示铺到后 ~50%，收在"保持静止的阅读"上——静止优于坏运动。布局用 inline 词汇：framing（centered / rule-of-thirds / split-screen / layered-depth / asymmetric 60-40 / triptych / full-width strip，整片 ≥3 种取景且不连续重复）、density（主视觉 ≥40% 画布、≥3 深度层）、hierarchy（size 3:1 / weight 800 vs 400 / contrast / 上三分位 / motion 中至少取 2）、depth（size / blur / opacity gradient / overlap / shadow-stack / counter-scale）。禁止：导航栏、页脚、滚动条、真实光标/浏览器 chrome、通用装饰形状、紫色-蓝色"AI"渐变。## Video direction块在 STORYBOARD 顶部只写一次，每帧 Scene 只写增量。

运动信条（skills/pr-to-video/references/motion-language.md）四条加载规则：

Smooth beats bouncy——power3长尾缓动是默认，back.out/bounce.out/elastic.out是头号劝退项，overshoot 降级为罕见的显式俏皮例外。
后 ~50% 按 VO 顺序揭示——反 PowerPoint 机制；前 ~25% 只放 VO 当下在说的东西。
没有 lazy breathing、没有坏的慢 pan/push——"宁无运动，不要坏运动"；hold 期间唯一被认可的活性是微妙 jitter。
内部接缝是速度匹配的切——zoom-through / cut-the-curve / waterfall 见 skills/pr-to-video/references/cut-catalog.md。

九、Quick Reference：与捕获型工作流的差异

PR 增量 vs 捕获素材型工作流（skills/pr-to-video/SKILL.md 的 Quick Reference 小结）：

无 Step 1 capture：ghCLI 把 PR 摄入合成capture/extracted/包（tokens.json+visible-text.txt+people.json）；唯一真实素材是贡献者assets/<login>.png头像（credits close）；无asset-descriptions.md、无 asset-staging 步骤。
代码 beat 由code-*registry 块在 code-editorial 的海军蓝 Code Surface 上渲染；风格恒定code-editorial。
自带脚本清单：fetch-pr（PR →capture/pr.json+diff.patch，大 PR 安全、无 scratch）、ingest（离线合成 capture 包）、fetch-people-avatars（头像 →assets/）；共享引擎build-frame（预设采纳 + 品牌 remix）、audio（TTS/BGM/SFX/时长同步）、captions、transitions（inject + verify）、assemble-index；其余全部交给hyperframesCLI。
格式：landscape1920x1080/ portrait1080x1920/ square1080x1080，由目的地推导，在 storyboard frontmatter 中一次性设置；竖版/方版按 visual-design.md 的指引纵向堆叠布局，居中 hero 锚在 y ≈ 0.42 × height。

整套工作流的测试覆盖可在 skills/pr-to-video/scripts/ 下的assemble-index.test.mjs、captions.test.mjs、frame-contract.test.mjs、workflow-guardrails.test.mjs中进一步研读；worker 角色契约见 skills/pr-to-video/sub-agents/frame-worker.md，它与该技能../hyperframes-animation/rules/、hyperframes-creative一起承载全部设计与运动规则，而不把这些规则塞进本技能本体。

【免费下载链接】hyperframesWrite HTML. Render video. Built for agents.项目地址: https://gitcode.com/GitHub_Trending/hy/hyperframes

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析