general-video

**插件安装：**如果此技能位于 HyperFrames 插件中，请在执行设置或检查更新命令前，遵循插件执行规则。独立安装请遵循下方的更新说明。

通用视频

除非此工作流刚刚读取过，否则请在开始时运行 npx hyperframes usage --json，然后在关键节点（例如完成草稿后、渲染前）再次检查。读取可用窗口和重置时间。如果用量未知，请如实说明，不要猜测额度；范围和工作流选择由用户决定。

使用此工作流前，请运行：

npx hyperframes skills update general-video

如果命令成功且无操作，说明此技能是最新版本。若更新失败，请明确指出，不要凭记忆继续操作。

1. 应用跨领域的源适配器

• **媒体：**对于任何音频、图像、图标、徽标、语音、调色、LUT、处理效果、字幕或媒体操作需求，请加载 /media-use，并遵循 ../media-use/references/resolve.md（解析、采用、复用）和 ../media-use/references/setup-providers.md（提供方、身份验证）。对于模糊的素材反馈和指定风格，请在编辑前查阅 ../media-use/references/media-treatments.md；不要用 CSS/SVG/不透明度临时实现受支持的媒体效果。首次执行需要身份验证的提供方操作前，请运行 npx hyperframes auth status，并原样转达其输出。如果未登录，请按照 ../hyperframes/references/brief-contract.md 中的限制处理：协作模式下，等待用户登录或明确选择离线方案；自主模式下，说明状态并通过可用的离线提供方继续操作。如果没有离线提供方能够满足所需能力，请说明阻碍。仅在本地采用资源时，无需执行身份验证限制。
• **Figma：**如果任何输入是 figma.com URL，请先运行 /figma。基于导出的资源、令牌、组件或分镜帧进行构建。不要直接调用 Figma 连接器，因为这会跳过 SVG 消毒、媒体来源追踪和品牌令牌绑定。

这些适配器不会改变 /hyperframes 所选的工作流。

2. 从项目状态开始

应用第一个匹配的行；不要评估后续状态行：

状态	操作
特定编辑	执行编辑，保留现有项目决策，然后重新运行受影响的检查。不要重新开始需求探索。
存在 BRIEF.md	读取该文件。如果 workflow 指定了其他工作流，且 flow 不是 companion，则交接。不要询问需求问题。
没有需求文档，但存在 hyperframes.json 或 STORYBOARD.md	根据文件和记录的偏好继续。仅根据已知事实补充 BRIEF.md。
全新创建	运行 /hyperframes 及其意图层。仅当 workflow: general-video 或 flow: companion 时才返回此处。

对于新项目，请根据需求文档选择 kebab-case 目录名，并在编写需求文档前搭建项目框架：

npx hyperframes init "videos/<project>" --non-interactive --example=blank --skill=general-video

然后使用 ../hyperframes/references/brief-format.md 在项目根目录创建 BRIEF.md。对于现有项目，根目录是包含 hyperframes.json 的目录。仅使用 node <MEDIA_DIR>/scripts/prefs.mjs record --hyperframes <PROJECT_ROOT> 记录需求文档格式中列出的、已确认且有偏好依据的字段；切勿记录推断出的默认值。此处的 <MEDIA_DIR> 是已安装的 /media-use 技能目录，<PROJECT_ROOT> 是包含 hyperframes.json 的目录。如果意图层采用了方案，请立即使用 node <MEDIA_DIR>/scripts/recipe.mjs use --hyperframes <PROJECT_ROOT> --name <name> 应用，无需再次询问。

3. 解读运行形态

仅使用 ../hyperframes/references/brief-contract.md 中的规范术语：

字段	含义	效果
flow	由谁主导	automation：选择并执行路线。companion：在对话中共同创作。
storyboard	构建前的规划、草拟和审阅	yes：运行规划和草图审阅（boards/storyboard.html，格式见 ../hyperframes-creative/references/storyboard-recipe.md）。no：不经此步骤直接构建。
派生的 mode	检查点关卡的行为方式	遵循简报契约。绝不要询问用户要使用哪种模式。

不要为这些状态创造同义词。持续表达“直接构建”的意图由意图层处理，并以 flow: automation、storyboard: no 的形式传入。

• 对于 flow: automation，选择路线，并在首次进度更新中用一行说明。
• 对于具体编辑，直接进行编辑，不要另行创造路线。

对于现有素材的硬切、裁剪、拼接或重新排序，将同一视频源复制到多个片段元素中。在每个副本上，通过 data-media-start 和 data-duration 设置源范围，然后通过 data-start 设置编排位置和顺序。每个视频片段都保留其声音：声音留在片段上（data-has-audio="true"），因此裁切视频时也会裁切其声音。/hyperframes-core 负责此类时间编辑；仅在内层包装器上进行缩放、强调、平移、裁剪、遮罩或 clip-path 等视觉属性动画时，才使用 /hyperframes-keyframes。 复制 ../hyperframes-core/references/creator-editing-recipes.md 中的完整契约。

Companion 流程

当 flow: companion 时：

• 阅读 BRIEF.md，并将已接受的 ## Assets 和 ## Customizations 与项目产物进行核对。完成仍待处理的已接受工作；已完成的工作保持原样；不要把已接受的能力再次当作新能力推荐。
• 以导演的身份到场，而非承包商。 选择 companion 的用户希望参与其中并追求品质；坦诚的回应应是你能设计出的最佳方案，而不是你能勉强辩护的最小方案。第一版计划就是方案的上限：故事弧线（借鉴最贴近的类型视角——菜单 § Genre lenses）、设计规范、每个场景的动态处理并注明名称（§ 5 的计划规范）、转场、音频标识——音乐与音效标记，或经过设计的静默——放置用户素材，以及经过设计的开场和收尾。用一行说明每个层次带来什么；提及昂贵项目（渲染时间、登录、计费）时明确标出。由用户将方案精简；绝不能让用户逐项审批、亲自拼凑方案。
• 上限属于创意概念，而非工具箱。 每个层次都必须服务于 brief 的信息——无论什么视频都能套用的方案只是装饰。制作水准可以达到上限；内容绝不能超出用户的要求（§ 6）。
• 在各检查点之间，../hyperframes/references/capability-menu.md 有两种用途。作为触发清单：用户提到相关输入或构建进入需要该能力的阶段时，就推荐相应能力。作为每轮的升级渠道：计划、草图或构建检查点可以附带一两条有依据的推荐，指向用户正在查看的素材（“场景 3 的数据统计适合采用逐步计数的处理方式”）。推荐前先阅读；切勿倾倒完整目录。
• 用户接受某项能力后，立即制作其产物，并在 BRIEF.md 中对应的正文部分记录该决定。只有用户明确更改偏好时，才改写 frontmatter 字段并记录已确认的偏好。
• 保持相同的故事板、验证、最终预览和渲染审批关卡。Companion 改变的是由谁掌舵，而非质量要求。

4. 每个阶段开始前加载必需知识

符合条件时，以下内容为必读：

条件	行动前阅读
任何合成 HTML 或场景布局	/hyperframes-core；阅读 references/determinism-rules.md，了解其布局约定
任何复杂创作或视觉处理	/hyperframes-creative → references/house-style.md 和 references/video-composition.md
任何运动、动画或场景转场	/hyperframes-animation；按照其中的路由说明，查阅相应的规则、适配器、蓝图或转场参考资料
storyboard: yes	../hyperframes/references/storyboard-format.md 和 ../hyperframes/references/review-loop.md
任何媒体素材或操作，包括旁白、BGM、SFX、字幕、调色或变换	/media-use（对于这些用途，优先使用宿主应用自带的音乐和音效工具）；如需了解框架中的播放和放置方式，也要阅读 /hyperframes-core → references/variables-and-media.md
多场景组装	../hyperframes/references/production-loop.md
flow: companion，在制定第一个计划之前	/hyperframes-creative → references/story-spine.md 和 references/house-style.md；最贴近的类型视角，以及完整的 ../hyperframes/references/capability-menu.md——上限方案应基于这些内容设计，而非凭记忆构思
提供、捕获伴侣能力、节拍网格、生成式视频、地图、发布或跨工作流能力	../hyperframes/references/capability-menu.md
存在设计规范，且尚未最终批准时	/hyperframes-creative → references/design-adherence.md

不要凭记忆代替阅读这些资料。只有实际加载相应参考资料，渐进式披露才能节省上下文。

5. 执行合成

按以下依赖顺序执行。仅当某个阶段的输入缺失时，才跳过该阶段。

1. 规划。 说明观众的情绪历程、结构、节奏和时长决定因素。简短的单场景使用一个文件；有三个或更多明确的场景切换，或有任何复用场景时，使用子合成。阅读 /hyperframes-creative → references/story-spine.md，了解叙事弧线；阅读 references/beat-direction.md，了解节奏；阅读 /hyperframes-core → references/composition-patterns.md，了解结构。对于开放式的多场景需求，通过 /hyperframes-creative → references/prompt-expansion.md 扩展提示词。多场景规划要标注每个场景的形式：适用时，引用 /hyperframes-animation → blueprints-index.md 中的蓝图 ID；若没有适用蓝图，则引用 rules-index.md 中组合使用的规则名称——动作名称必须来自这些索引，不能自行编造。故事本身决定有哪些场景；引用内容只负责装饰。在规划自行构建的任何指定视觉效果之前，先搜索实时目录：对于需求中提到的每种视觉效果、特效、处理效果或转场——如“CRT 扫描线”、“故障效果”、“胶片颗粒”、“闪光扫过”、“彩纸爆发”——运行 npx hyperframes catalog --query "<用通俗英语描述该效果>" --json，并阅读排名靠前的结果，然后再在规划中说明如何构建该效果。搜索无需安装任何内容：不需要项目、不需要事先执行 add，也不需要账号。它会在任何目录中对整个托管注册表（约 400 个区块和组件）进行排名，因此也适用于用户在构建过程中临时提出的视觉效果。规划中指定的区块在阶段 3 安装；只有在搜索后仍找不到合适内容时，才手动制作视觉效果。多场景规划还要记录为调度产物：在 STORYBOARD.md 中为每个场景创建一个 ## Frame N 区块，包含 status: outline、声明的 src:、蓝图／规则引用和节拍文本——即使 storyboard: no 也要如此。区块是调度单元；故事板只是审核界面。

2. 按需审核规划。 对于 storyboard: yes，围绕这些区块运行共享审核循环。对于 storyboard: no，直接继续，不暂停审核规划，也不生成草图表。如果无论如何都要暂停审核规划，就在这次暂停时一并取得子代理委派授权（codex 在第 4 步调度时需要），不要等到稍后再停一次。

3. 处理依赖项。 并行工作前先安装注册表区块。准备用户素材、采用现有媒体，并且只处理需求所必需的内容。若时长由音频时间决定，则尽早处理音频。

4. 构建场景。 对于简短的单场景作品，先实现该场景最醒目的时刻，再添加动态效果（若已有确认的线框，它就是最终状态，且不得重新绘制），然后依据引用的蓝图或规则制作动画——编写动态效果前，先阅读完整的配方正文（/hyperframes-animation → blueprints/<id>.md、rules/<id>.md）。

   只有达到一定规模时，调度才划算。 编写任务包和预热全新的工作线程上下文会耗费实际的时间和 token：最多约 6 个短场景的影片，在当前上下文中逐个场景内联构建会更快（实测：5 个短场景，内联约 9 分钟，打包后约 21 分钟）。只有当规划超出这一规模——场景更多，或单个场景本身工作量很大——才分派任务；分派时，让每个工作线程负责 2–3 个场景，而不是一个，并且在同一轮中启动所有工作线程（第二轮几乎会让耗时翻倍）。分派时：

   node <SKILL_DIR>/scripts/frame-packets.mjs --project "$PROJECT_DIR" --storyboard "$PROJECT_DIR/STORYBOARD.md" 构建器会在 .hyperframes/frame-packets/ 下为每个场景写入一个有界数据包（场景中精确的分镜块 + 蓝图正文 + 每条引用规则的配方，全部内联），并写入 _role.md（将 ../hyperframes/references/frame-worker-core.md + 此技能的 sub-agents/frame-worker.md 原样拼接而成——即完整的工作角色）。分派工作者——每个工作者处理 2–3 个场景数据包，全部在同一轮中完成（../hyperframes/references/subagent-dispatch.md）；每个工作者的提示词都包含 _role.md 及其数据包——可完整粘贴，或提供文件路径让工作者先读取（两种方式等效）——以及包含 PROJECT_DIR、其 frame_id 和画布尺寸的分派上下文。等待每个场景精确的分镜 src（例如 compositions/frames/<frame_id>.html）及其相邻的 <frame_id>.motion.json 侧车文件。工作者只能读取自己的数据包和设计真相文件；不得打开 STORYBOARD.md 或技能文档。若没有委派渠道，则按顺序回退：在此上下文中一次处理一个数据包，仍仅依据数据包工作。

5. 合并动作侧车文件。 收集各分镜 src 相邻的工作者 <frame_id>.motion.json 文件，并将其中的时长和退出／进入向量用于组装；若已安装 doctrine chain（/motion-doctrine），则在标记衔接点前将它们转换为项目台账。

6. 组装。 使用制作流程挂载场景、媒体、转场、字幕和音频。实际语音时长优先于估算值。只要有音乐垫音轨与任何语音轨道同时播放，就必须先裁切垫音再进行验证：/hyperframes-audio → scripts/carve.mjs --comp index.html。仅降低音量并不能完成混音。

7. 验证。 首次 HTML 编写后以及结构变更后，使用 npx hyperframes lint 快速获取反馈。最终关卡运行 npx hyperframes check；它会在内部重新运行 lint，因此不要在它之前立即单独重复运行 lint。对于子合成，检查中点快照。对于多场景项目，检查动画映射。

8. 最终批准。 检查通过后，打开最终的 Studio 预览——自动模式下也一样，在任何渲染之前打开：打开预览无需询问。询问是否渲染或修改（自动模式下：唯一需要保留的问题）。只有获批后才渲染。

6. 始终适用的关卡

严格限定范围

制作用户要求的内容。标题卡不等于标题卡再加三个场景、音乐和字幕。添加内容前先提出建议。

编写 HTML 前确定设计

按以下顺序确定设计来源：frame.md → design.md → DESIGN.md。将找到的第一个文件视为品牌准则。

如果没有设计规范，则在编写合成 HTML 前完成以下四项：

1. 依据 house-style.md 和 video-composition.md 确立视觉形象。
2. 为每个非简单创作写一句话，说明其概念切入点。
3. 从 /hyperframes-creative → references/typography.md 中选择一组可嵌入的字体搭配；不要假定云端渲染环境中存在未打包的展示字体。
4. 定义焦点元素、边缘锚点、辅助细节和背景处理方式。

让画面密度匹配用户要求的格式和信息。密度示例仅为产出的画面提供指导，并不意味着可以自行编造主张、场景或固定数量的元素。

对于指定的风格或情绪，请阅读 /hyperframes-creative → references/visual-styles.md。当用户需要进行视觉选择，且没有合适的内置预设时，请阅读 /hyperframes-creative → references/design-picker.md，并在那里运行交互式设计选择。

遵守合成约定

定时元素使用 class="clip"；根元素及相关祖先元素都要设定尺寸；每个合成在 window.__timelines 上注册一个暂停且可安全跳转的时间线；渲染必须具备确定性。不得在渲染期间发起网络请求、读取时钟或使用未设种子的随机数。

安全借鉴工作流

如果作品风格接近已发布的工作流，可以借鉴其类型范例。先运行 npx hyperframes skills update <workflow-name>。借鉴其叙事结构和审美取向，不要复用其私有脚本、流水线状态或目录约定。通用构建仍由此技能负责。

7. 完成

只有满足以下条件，运行才算完成：

• 已实现请求的范围；
• 对于 flow: companion，交付的不只是范围，还包括完整的设计方案：每个场景都实现了所引用的蓝图或规则，呈现了音频风格（或明确选择静音并说明），片头和片尾经过设计，而非采用默认设置；
• npx hyperframes check 检查通过，包括其内置的 lint 阶段；
• 如果存在设计规范，已根据 /hyperframes-creative → references/design-adherence.md 审查设计遵循情况；
• 已解决对比度问题；
• 适用时，已检查子合成快照；
• 自主交接内容包含已检查的联系表或快照表；多场景表使用各场景的中点；
• 交接内容在适用时注明最终预览或渲染产物，并报告基于时长的交付内容的实际时长；
• 对于多场景工作，已审查 hyperframes-animation/scripts/animation-map.mjs；
• 渲染前，用户已批准最终 Studio 预览；
• 如果请求了渲染，已验证渲染文件。

最终批准后，可按照 ../hyperframes/references/review-loop.md § 4，询问一次是否要将本次运行冻结为配方。