通用视频 是做什么的？
在依赖此工作流之前，请运行：
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-core/references/brief-contract.md中的门控：协作模式等待登录或明确的离线选择；自主模式报告状态并通过可用的离线提供商继续。当没有离线提供商能满足所需能力时，显示一个阻碍。仅本地采用不需要认证门控。 - Figma： 如果任何输入是
figma.comURL，首先运行/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，选择路线并在第一次进度更新中用一行说明。 - 对于特定编辑，进行编辑而不发明新路线。
对于现有素材的硬切、修剪、拼接或重新排序，将同一视频源复制到多个剪辑元素中。在每个副本上，使用 data-media-start 加 data-duration 设置源范围，然后使用 data-start 设置创作位置/顺序。单独创作的音频在匹配的 <audio> 元素上遵循相同的剪辑范围和时序。/hyperframes-core 拥有此时间编辑；仅对内部包装器上的视觉属性动画（如缩放、推拉、平移、裁切、遮罩或 clip-path）使用 /hyperframes-keyframes。
从 ../hyperframes-core/references/creator-editing-recipes.md 复制完整约定。
伴生流程
当 flow: companion 时：
- 读取
BRIEF.md并将已接受的## Assets和## Customizations与项目工件协调。完成仍待处理的已接受工作；已完成的工作保持不变；不要再次提供已接受的能力，仿佛它是新的。 - 以导演而非承包商的姿态出现。 选择伴生模式的用户追求参与和质量；诚实的回应是你能设计的最佳版本，而不是你能辩护的最小版本。第一个计划是天花板式的处理：故事弧（借用最近的类型镜头 —— 菜单§类型镜头）、设计规范、每个场景的动画处理名称引用（§5的计划规范）、转场、音频身份——音乐和声音标记，或有意为之的静默——用户的素材放置，以及设计好的开场和结尾。用一句话说明每个图层增加了什么；标记出昂贵的那些（渲染时间、登录、计费）。用户会修剪处理方案；他们永远不应该一个一个审批地组装。
- 天花板属于概念，而不是工具箱。 每个图层都必须服务于简介的信息——一种无论什么视频都会以同样方式装扮的处理只是装饰。匠心追求天花板；内容永远不会超出要求（§6）。
- 在检查点之间，
../hyperframes/references/capability-menu.md有两个作用。作为触发器列表：当用户提到某个能力的输入或构建到达其需求时，提供相关能力。作为每次迭代的升级通道：计划、草图或构建检查点可以带有一两个追踪到的提议，指向用户正在查看的材料（“场景3的统计数据需要计数处理”）。在提供之前阅读它；永远不要倾倒整个目录。 - 用户接受某项能力后，立即生成其工件并将决策记录在匹配的
BRIEF.md正文部分。仅当用户明确更改时才重写前置字段并记录确认的首选项。 - 保持相同的看板、验证、最终预览和渲染审批门控。伴生模式改变的是谁在驾驶，而不是质量要求什么。
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 |
| 任何媒体资产或操作，包括旁白、背景音乐、音效、字幕、调色或变换 | /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扩展提示。多场景计划引用每个场景的形状：当适合时来自/hyperframes-animation→blueprints-index.md的蓝图ID，或当没有蓝图适合时，引用其组成的命名规则——运动名称来自这些索引，永远不要发明。故事真实性决定哪些场景存在；引用为其着装。多场景计划也记录为分派工件：每个场景一个## Frame N块在STORYBOARD.md中——status: outline、声明的src:、蓝图/规则引用和节拍文本——即使当storyboard: no。该块是分派单元；看板仅仅是审查界面。 -
应要求审查计划。 对于
storyboard: yes，在这些块上运行共享审查循环。对于storyboard: no，继续而不打开看板。当计划暂停无论如何发生时，将子代理委托授权（步骤4分派时 codex 需要）折叠到该暂停中，而不是稍后再次停止。 -
解决依赖。 在并行工作前安装注册表块。阶段用户资产，采用现有媒体，并仅解决简介所需的内容。当其时序驱动持续时间时，尽早启动音频。
-
构建场景。 对于短场景作品，在添加运动之前，在其最可见的时刻实现场景（确认的线框（如果存在）就是该最终状态且不得重绘），然后根据引用的蓝图或规则进行动画——在编写运动之前阅读完整的配方正文（
/hyperframes-animation→blueprints/<id>.md、rules/<id>.md）。分派仅在规模上值得。 编写数据包和预热新的工作上下文需要实际的时间和令牌：一部最多约6个短场景的电影内联构建更快，在此上下文中，一个接一个地构建（测量：5个短场景 ≈ 9
…
[truncated for translation]