发布视频
将真实产品转化为清晰的视觉故事：痛点、变化、运作方式以及下一步行动。使用 HyperFrames 作为引擎。保持用户选择的模型作为管理者。不要替换引擎，也不要创建视频编辑器、模板库或动画框架。
1. 明确简介
首先阅读用户提供的简介、产品、素材和现有项目。恢复现有工作。仅询问会改变视频的缺失事实；不要重复已回答的问题。仅凭产品名称不足以支持功能主张。对于输入稀疏的情况，在编写故事板之前，先确定受众、有意义的承诺和最终行动。
对于提供的 URL，检查实际产品和官方品牌来源。在适当情况下使用 HyperFrames 捕获；遵循 upstream.md 中固定的捕获失败规则。捕获失败时，不要编造替代网站。对于“按原样展示”的视频，使用实际屏幕作为基础。除非获得编辑授权，否则保留提供的精确文案。在视频项目的简短 BRIEF.md 中记录声明、来源、资产权限以及任何假设。未经授权，切勿在公共演示中包含私人材料。
使用产品的颜色、字体、密度和实际 UI。选择具有有意义的动态、可读字体和精心节奏的具体视觉方向。有选择地阅读上游创意和运动参考。参考资料研究 演示了技巧，而非强制性的内部风格。虚构示例必须明确标注；不要将其变成暗示的真实客户结果。
2. 准备项目
阅读 upstream.md 并验证固定的源和 CLI，然后再依赖它们。使用上游的 HTML 组合协定、诊断和渲染。仅读取所需的领域参考；不要将整个源树复制到交付物中，也不要静默刷新到最新版本。
创建专用视频项目。使用 project-format.md 定义 project.json。在故事板中商定输出尺寸、帧率、持续时间和音频选择。对于 X，在导出前验证当前官方的上传要求。默认为短片、静音友好型电影；未经授权，不要购买媒体或调用付费语音提供商。缺少资产需要本地、获得许可的替代品，且与简介一致或提出具体问题，绝不能使用损坏的占位符。
3. 设计、展示并获得批准
编写精炼脚本：每个场景一个清晰的想法，真实的产品证据，有价值的回报。为每个场景创建完整的静态、设计好的 HTML 帧，包含实际提议的文案、布局、调色板和素材。仅文本描述和线框图不是审查用的产物。在整个影片中保持一个连续的产品示例。以可读的比例显示重要的 UI，并留出时间理解每个操作。
每个帧必须是自包含的静态 HTML，包含内联 CSS。使用本地的、声明的图像/字体资产；请参考格式参考。以完整输出尺寸和推送比例检查帧。在 project.json 中包含精确标题、可选旁白、持续时间和预期动态，然后运行：
python3 <SKILL_DIR>/scripts/launch_video.py storyboard <PROJECT_DIR>
为用户打开生成的 storyboard.html。先自己检查每个帧。要求用户对显示的版本或特定场景的更改给予批准。在获得用户明确批准之前，不要进行完整动画制作或渲染。 沉默、泛泛的早期“是”、对构建想法的接受以及自动模式不构成对未见故事板的批准。在此门控之前，允许进行中性的技术渲染器探测。
仅在用户批准显示的版本后，记录他们的实际决定：
python3 <SKILL_DIR>/scripts/launch_video.py record-approval <PROJECT_DIR> \
--version <DISPLAYED_SHA256> --approver <USER_NAME> --decision '<ACTUAL_APPROVAL_TEXT>'
python3 <SKILL_DIR>/scripts/launch_video.py check-approval <PROJECT_DIR>
收据绑定清单、帧字节、素材和生成的故事板。它记录了一个人类的决定；它不认证发言者或解释任意文本是否意味着批准。切勿伪造收据。默认情况下，将批准记录设为私有。
4. 制作已批准故事的动画
使用固定的 HyperFrames 动画规则和蓝图。重用已批准的、设计好的帧作为组合基础。每个场景应展示一个实际动作和结果；动态必须支持故事。使用可定位的时间线。在实现特定技术之前，阅读相关的上游规则。在连续过渡中匹配位置、比例、方向和透明度。避免遮挡产品或快速闪烁的动态。
按照格式参考创建 index.html 和每个已批准场景的子组合。保持 ID/顺序、精确文本、时间、尺寸和资产身份与已批准的故事板一致。辅助工具检查结构、文本和时间；你自己检查视觉和资产。它无法仅从源证明语义保真度。不要编辑已批准的帧以掩盖偏差。
任何请求的故事、文案、资产、布局、时长或音频更改都需要修订后的故事板和新的批准。保留先前的版本。修复已批准意图的运动的修复可以继续进行，然后重新运行受影响的检查。如果使用代理，给每个代理一个精确的场景和非重叠的文件所有权；管理者拥有组合和 QA。
5. 检查、渲染和交付
在项目目录中使用固定的 CLI 运行 lint、check、keyframes . --json 和 snapshot --at <场景中点和过渡边界>。检查每个场景、开头/结尾以及每个剪辑的两侧。打开 preview --background 并以正常速度观看完整动态。检查可读性、时间、重叠、裁剪、资产加载、过渡连续性和静音理解性。对于音频，还需检查权限、同步、裁剪和结尾。通过静态检查并不能证明视觉质量。
在批准和预渲染视觉 QA 之后，通过辅助工具进行渲染：
python3 <SKILL_DIR>/scripts/launch_video.py render <PROJECT_DIR> --output output/video.mp4
这会调用 HyperFrames 0.8.37 和 ffprobe，检查输出是否符合批准的尺寸/帧率/时长/音频，并写入 .qa.json 收据。其视觉 QA 状态保持待定：在交付前检查实际的 MP4，提取代表性帧，并观看完整播放。分别报告证据和判断。不要因为编码成功就标记结果为完成。
失败时，读取错误，修复其具体原因，并重复受影响的检查。保留现有视频；在检查部分失败的渲染后，选择新的输出路径。切勿切换引擎、使用旧输出作为新结果或隐藏缺失的能力。如果受阻，说明剩余内容并提供已完成的、可审查的工作。
交付 MP4、设计好的故事板、用于修订的场景 ID、尺寸/时长/音频、可重现的命令以及诚实的 QA 笔记。仅在请求时发布。不要承诺“病毒式传播”、一次成型质量或未量化的时间/令牌节省。