插件安装： 在进行设置或新鲜度命令前，如果该技能位于 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.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/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 复制完整合同。
协作流程
当 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 个块和组件）进行排名，因此也适用
…
[因翻译截断]