通用视频
在依赖此工作流之前，请运行：
npx hyperframes skills update general-video
成功的 no-op 表示技能是最新的。如果更新失败，请报告错误，不要依赖内存中的版本继续。
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-core/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-core/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-core/references/brief-contract.md 的规范术语：
| 字段 | 含义 | 效果 |
|---|---|---|
flow | 谁驱动 | automation：选择并执行路线。companion：在对话中共同创作。 |
storyboard | 故事板是否为审查界面 | yes：运行计划和草图审查。no：无需故事板直接构建。 |
派生的 mode | 检查点关卡的行为方式 | 遵循简介契约。不要询问用户来命名模式。 |
不要为这些状态发明同义词。一个持续的“直接构建它”信号由意图层处理，并作为 flow: automation、storyboard: no 到达。
- 对于
flow: automation，选择路线并在第一次进度更新中用一行说明。 - 对于特定编辑，进行编辑，不要发明新路线。
协作流程
当 flow: companion 时：
- 读取
BRIEF.md并将已接受的## Assets和## Customizations与项目构件进行核对。完成仍然待处理的已接受工作；已完成的工作保持不变；不要将已接受的功能再次作为新功能提供。 - 以导演而非承包商的身份到来。 选择协作方式的用户选择了参与度和质量；诚实的回应是你能设计的最佳版本，而不是你能辩护的最小版本。第一计划是天花板级方案：故事弧（借用最近的体裁视角——菜单 § 体裁视角）、设计规格、按名称引用的每个场景的动态处理（§ 5 的计划纪律）、转场、音频标识——音乐和声音标记，或刻意的静音——用户材料的放置，以及设计好的开场和结束语。用一句话说明每个图层添加了什么；在提及它们时标注出昂贵的部分（渲染时间、登录、计费）。用户向下调整方案；他们永远不应该逐个批准地组装一个方案。
- 天花板属于概念，而非工具箱。 每个图层都必须服务于简介的信息——一个会以相同方式装饰任何视频的处理方案只是装饰。工艺上升至天花板；内容永远不会超出所要求的范围（§ 6）。
- 在检查点之间，
../hyperframes/references/capability-menu.md有两种工作方式。作为触发列表：当用户提到其输入或构建达到其需求时，提供相关的功能。作为每次通过（pass）的升级通道：一个计划、草图或构建检查点可以附带一到两个有针对性的报价，指向用户正在查看的材料（“场景 3 的状态想要计数处理”）。在提供之前阅读它；永远不要倾倒整个目录。 - 在用户接受一个功能后，立即生成其构件，并在匹配的
BRIEF.md主体部分中记录该决策。仅当用户明确更改时，才重写一个前置内容字段并记录已确认的偏好。 - 保持相同的故事板、验证、最终预览和渲染批准关卡。
Companion改变的是谁在掌舵，而不是质量要求什么。
4. 在每个阶段之前加载必需知识
当条件匹配时，以下读取是强制性的：
| 条件 | 读取内容 |
|---|---|
| 任何合成 HTML 或场景布局 | /hyperframes-core；使用 references/determinism-rules.md 获取其布局契约 |
| 任何非平凡的创作或视觉处理 | /hyperframes-creative → references/house-style.md 和 references/video-composition.md |
| 任何动态、动画或场景转场 | /hyperframes-animation；遵循其路由到匹配的规则、适配器、蓝图或转场参考 |
storyboard: yes | ../hyperframes-core/references/storyboard-format.md 和 ../hyperframes-core/references/review-loop.md |
| 任何媒体资产或操作，包括旁白、BGM、SFX、字幕、调色或变换 | /media-use；对于框架播放和放置，还需读取 /hyperframes-core → references/variables-and-media.md |
| 多场景组装 | ../hyperframes-core/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. 执行合成
使用此依赖顺序。仅当其输入缺失时，才跳过某个阶段。
-
计划。 说明观众弧、结构、节奏和时长驱动因素。对于短的单场景，使用一个文件；对于三个或更多硬性场景切换或任何重用场景，使用子合成。阅读
/hyperframes-creative→references/story-spine.md了解叙事弧，references/beat-direction.md了解节奏，以及/hyperframes-core→references/composition-patterns.md了解结构。对于开放式的多场景简介，通过/hyperframes-creative→references/prompt-expansion.md扩展提示。一个多场景计划需要引用每个场景的形状：当有匹配的蓝图 ID 时，从/hyperframes-animation→blueprints-index.md获取；如果无匹配，则引用其组合的命名规则（来自rules-index.md），当两者都不适用时。动态名称来自这些索引，从不发明。故事的真实性决定哪些场景存在；引用用于装饰它们。一个多场景计划也作为调度构件记录：在STORYBOARD.md中，每个场景对应一个## Frame N块——status: outline、声明的src:、蓝图/规则引用和节拍文本——即使在storyboard: no时也是如此。该块是调度单元；故事板仅是审查界面。 -
在请求时审查计划。 对于
storyboard: yes，在这些块上运行共享的审查循环。对于storyboard: no，继续执行，不打开故事板。当计划暂停无论如何都会发生时，将子代理委派授权（步骤 4 的调度可能需要，例如在 Codex 中）折叠到该暂停中，而不是稍后再次停止。 -
解决依赖项。 在并行工作之前安装注册表块。搁置用户资产，采用现有媒体，仅解决简介所需的内容。当音频的时序驱动时长时，尽早开始音频工作。
-
构建场景。 对于短的单场景作品，在添加动态之前，在其最可见的时刻实现场景（当存在时，已确认的线框图是该最终状态，不得重绘），然后根据其引用的蓝图或规则进行动画处理——在编写动态代码之前，阅读完整的配方主体（
/hyperframes-animation→blueprints/<id>.md、rules/<id>.md）。调度仅在规模化时才物有所值。 编写数据包和预热新的工作上下文会花费实际的时间和令牌：一个最多约 6 个短场景的电影在此上下文中内联构建更快，一个接一个场景（测量结果：5 个短场景 ≈ 9 分钟内联 vs ≈ 21 分钟数据包化）。仅在计划超出此范围时（更多场景，或单个场景较重），才进行分派，然后给予每个工作器 2–3 个场景，而不是一个，并且在 单个波次 中生成 所有工作器（第二波次几乎会使时间窗口加倍）。当分派时：
node <SKILL_DIR>/scripts/frame-packets.mjs --project "$PROJECT_DIR" --storyboard "$PROJECT_DIR/STORYBOARD.md"构建器在
.hyperframes/frame-packets/下为每个场景编写一个有限的数据包（场景的确切故事板块 + 蓝图主体 + 每个引用的规则配方，内联）以及_role.md（`../hyperframes-core/references/frame-worker-