插件安装： 在执行设置或更新命令之前，当此技能位于HyperFrames插件内时，请遵循插件执行规则。独立安装则保留下面的更新说明。
通用视频
在依赖此工作流之前，请运行：
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.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：运行计划和草图审查（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中每个场景一个## 帧 N块——status: outline，声明的src:，蓝图/规则引用，以及节拍文本——即使当storyboard: no时。块是分派单元；故事板表只是审查表面。 - 在请求时审查计划。 对于
storyboard: yes，在这些块上运行共享审查循环。对于storyboard: no，继续而不进行计划暂停或草图页。当计划暂停发生...