miora-video-studio

miora 视频生成工作台

使用前提：当前环境已经配置 WorkBuddy / Miora 视频工具。若工具不可用，本 Skill 只能用于诊断与解释，不能替代实际的视频生成通道。

若环境同时提供下列 Skill，可以协同加载：

• miora-creative-core —— 底座：确认与费用边界、生成前参数怎么定、画布交付。
• miora-video-generation —— 决策：镜头语言、时长画幅、主体一致性、失败处置。

它们不是本 Skill 的安装前提；本 Skill 自身负责：完成信号怎么判、参数实测到哪、提示词怎么改。

---

1. 唯一的核心问题：完成信号

miora 生成进程与对话进程是分离的。由此推出五条，任一条都不能违背：

1. 完成信号来自落盘事实，不来自接口返回。 返回值可能整体丢失——实测发生过：15 秒视频生成成功、成片已落盘，调用方什么也没收到。把"没返回"当成"失败"是错的。反向情形同样存在：调用会阻塞到任务完成再返回 status: completed + resultFiles[].localPath（实测等约 6.4 分钟），此时仍要走一次 --wait 核验——用文件头读规格，不采信自报值。
   • 返回值里带了 localPath 时，那个绑定优先于文件扫描：立刻 --wait --claim <localPath> --job <作业名> 落账（见第 4 节；--claim 不是独立动作，必须和 --submit/--wait/--poll/--poll-all 之一同时给，否则 argparse 直接报错退出）。别让启发式扫描有机会把并发作业的成片算到你头上。
2. 提交之前先登记作业，再发起生成。顺序颠倒就失去跨轮追溯能力。
3. 生成后立刻轮询，不靠用户再发一句话。视频要 6 ~ 21 分钟，单轮等得完。
4. 规格以文件头为准，时长 / 分辨率 / 音轨自己读出来，不采信自报值。
5. 不重复提交。 状态不明不等于失败；重复提交会重复计费，且已提交的任务无法取消。

配套脚本 scripts/miora_watch.py 实现上述判定。

调用前需 connect_cloud_service 取会话凭据，把 clientTempToken 作为 tempKey 传给视频工具。凭据有效期不稳定——实测出现过同一 token 在同一分钟内第二次使用就被拒（AUTH_INVALID_TEMP_KEY）。所以：报 AUTH_*_TEMP_KEY 就重新取一次再重试；连续重试时干脆每次重取，比猜有效期省事。凭据内容不得展示给用户。

1.1 第 0 步：先查工具在不在

每次开工都查，不要凭上次的经验跳过——同一台机器上不同会话的可用性可能不同（实测过：同一台机器，一个会话里 mcp__miora__* 正常可用并成功出片，另一个新会话里完全没有注册）。

开工第一步确认当前会话的工具清单里有没有 mcp__miora__*。

判定分三步，顺序不能颠倒——两种"缺失"形态容易混判。

第一步：先看主工具清单。 如果 mcp__miora__miora_reference_to_video / mcp__miora__miora_text_to_video / mcp__miora__miora_write_canvas 这些直接出现在当前会话的可调用工具清单里，那就是可用，直接开工。 无需再做任何探查——它们不在 deferred 索引里，ToolSearch 天生搜不到它们。

第二步（仅当主清单里看不到 mcp__miora__* 时）： ToolSearch 用 queries: ["miora"] 搜。这里的结果只用于识别"server 条目在、子工具一个都没注册"的空壳状态：available_deferred_tools 里列着 mcp__miora，但对比 mcp__agent-mail / mcp__sheetagent 能看到人家的子工具名都展开了，miora 没有。

第三步（二次确认）： 用 DeferExecuteTool 探 mcp__miora__miora_reference_to_video——报 Tool "..." not found in the deferred tools index 才是决定性证据。

第四步（只在确诊缺失后做，用于分清"没配"还是"没启用"）： 三处落盘证据一起看，给用户的结论才具体。