插件安装： 在运行设置或更新命令之前，如果此技能位于 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 时返回当前流程。 |
对于新项目，请根据简报选择一个短横线分隔的目录名，并在编写简报前创建项目骨架：
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 设置创作位置/顺序。每个视频片段保留其声音：声音保留在片段上（data-has-audio="true"），因此剪切视频也会剪切其声音。/hyperframes-core 拥有此时间线编辑功能；/hyperframes-keyframes 仅用于视觉属性动画，如缩放、推拉、平移、裁剪、遮罩或内部包装器上的 clip-path。从 ../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 |
| 任何媒体资源或操作，包括旁白、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. 执行组合
使用此依赖顺序。仅当输入缺失时才跳过某一阶段。
-
计划。 说明观众弧线、结构、节奏和时长驱动因素。对于简短的单个场景使用一个文件；对于三个或更多硬场景切换或任何被重用的场景，使用子组合。阅读
/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:、蓝图/规则引用、预期的持续时间和节奏。用于建议场景存在的引用顺序优先级如下：- 简报中提供的用户资源
- 从
/media-use→ provider auth 路由使用的提供商素材 - 使用
/hyperframes-creative→ references/effects-moderation.md 中的合成视觉效果
在计划阶段，不要为主视觉处理方案之外的元素（如背景音乐）添加占位符。
-
草稿。 为每个场景创建
index.html，遵循/hyperframes-core→references/determinism-rules.md中的布局合约。对于运动，引用/hyperframes-animation→rules-index.md中的动画规则。对于子组合，使用<div data-controller="hyperframes--sub-composition">结构。 -
构建。 运行
npx hyperframes build并记录输出。如果构建失败，修复错误并重新构建。在继续之前，验证输出是否符合简报规范。 -
审查。 对于
storyboard: yes，运行npx hyperframes review并处理反馈。对于storyboard: no，在执行最终预览之前，运行npx hyperframes validate。 -
最终预览。 运行
npx hyperframes preview并等待用户批准。对于flow: automation，在预览前运行npx hyperframes validate。 -
渲染。 运行
npx hyperframes render。输出视频文件。
在所有阶段，记录决策并在 BRIEF.md 中标记完成。对于 flow: companion，在每个检查点提供功能菜单中的相关选项。