通用视频制作 是做什么的？
在依赖此工作流之前，请运行：
npx hyperframes skills update general-video
成功的无操作表示技能已是最新。请报告更新失败，而不是继续使用内存中的旧数据。
1. 应用通用资源适配器
- 媒体： 对于任何音频、图像、图标、LOGO、配音、调色、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：运行计划和草图审查（storyboard.html）。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/references/storyboard-format.md 和 ../hyperframes/references/review-loop.md |
| 任何媒体资源或操作，包括旁白、背景音乐、音效、字幕、调色或变换 | /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. 执行组合
使用此依赖顺序。仅当输入缺失时才跳过某个阶段。
- 计划。 说明观众视角弧、结构、节奏和时长驱动因素。对于短的单场景，使用一个文件；对于三个或更多硬场景切换或任何重复使用的场景，使用子组合。阅读
/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。该块是分发单元；故事板表仅是审查界面。 - 应请求审查计划。 对于
storyboard: yes，对这些块运行共享审查循环。对于storyboard: no，继续执行，无需计划暂停或草图界面。如果仍然发生了计划暂停，则将子代理委托授权（在第4步分发时需要）折叠到该暂停中，而不是稍后再次停止。 - 解析依赖项。 在并行工作之前安装注册表块。暂存用户资源，采纳现有的
…
[为翻译而截断]