ClawHub

xiaodu-movie-mode-official

v1.0.1

基于已安装的 xiaodu-control-official 编排观影场景。当用户说“开始观影模式”“我要看电影”“把房间调成适合看电影的状态”“准备看电影了”时使用。这个 skill 会复用 xiaodu-control-official 的现有脚本，对小度智能屏和小度 IoT 设备执行 scene-first...

⭐ 0· 96·0 current·0 all-time
by@dueros-mcp

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for dueros-mcp/xiaodu-movie-mode-official.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "xiaodu-movie-mode-official" (dueros-mcp/xiaodu-movie-mode-official) from ClawHub.
Skill page: https://clawhub.ai/dueros-mcp/xiaodu-movie-mode-official
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install xiaodu-movie-mode-official

ClawHub CLI

Package manager switcher

npx clawhub@latest install xiaodu-movie-mode-official
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
medium confidence
✓
Purpose & Capability
Name/description match the runtime instructions: the skill is an orchestrator that calls existing xiaodu-control-official scripts to prepare a room for movie watching. The required capabilities (listing scenes, controlling IoT, speaking) align with that purpose.
ℹ
Instruction Scope
SKILL.md explicitly instructs the agent to run local shell scripts (e.g., ../xiaodu-control-official/scripts/list_scenes.sh, control_iot.sh, speak.sh) and to read/update local preference files (XIAODU_CONTEXT.md, MEMORY.md) only when the user asks. This stays within the described purpose, but the skill references specific filesystem paths and files even though the registry metadata lists no required config paths—confirm those paths exist and inspect the referenced scripts/files before use.
✓
Install Mechanism
Instruction-only skill with no install spec and no external downloads — lowest install risk. It will only run shell commands if the agent is permitted to do so.
✓
Credentials
The skill requests no environment variables or credentials. Its actions are limited to local script invocation and optional local preference persistence, which are proportionate to an orchestrator of IoT/display devices.
ℹ
Persistence & Privilege
Skill may write to XIAODU_CONTEXT.md or MEMORY.md to persist user preferences, but only when the user explicitly asks. It does not request permanent/always-on privileges. Verify where these files are stored and that you are comfortable with the skill modifying them.
Assessment
This skill is coherent with its stated purpose, but before installing: (1) ensure the dependency skill/directory (xiaodu-control-official) and the referenced scripts actually exist where the skill expects them; (2) manually inspect the scripts (list_scenes.sh, control_iot.sh, control_xiaodu.sh, speak.sh, etc.) to confirm they perform only expected local IoT/display actions and do not contact unknown endpoints or exfiltrate data; (3) backup or review XIAODU_CONTEXT.md and MEMORY.md if present, since the skill may read/modify them when you ask it to remember preferences; (4) limit the agent's shell execution permissions or run in a sandbox if you are concerned about arbitrary script execution; and (5) understand this skill will control real devices (lights, curtains, TVs, projectors) — verify those devices and their control scripts are trusted. If any referenced script or path is missing or points to an unexpected location, do not enable the skill until resolved.

Like a lobster shell, security has layers — review code before you run it.

latestvk970mb4mtvx9nnmppatp7m1whh844z3z
96downloads
0stars
2versions
Updated 3w ago
v1.0.1
MIT-0
@dueros-mcp
latest
Download

xiaodu-movie-mode-official

定位

一个基于 xiaodu-control-official 的观影场景 orchestrator。

它不是电影搜索 skill，也不是播放器 skill，而是：

用户一句高层表达（“开始观影模式”）→ 系统先把房间和播放设备准备到“可以开始看”的状态 → 用户明确指定内容时，再继续进入播放层。

核心原则

观影模式默认负责“把房间和设备准备到可以开始看”的状态；只有在用户明确指定内容时，才继续进入内容播放层。

不默认替用户选电影，不默认自动播放一个平台里的内容。

基于 xiaodu-control-official 事实能力全集的统一规划框架

所有观影规划都只能建立在 xiaodu-control-official 已明确记录的能力 bucket 上。 不要加入想象中的设备族、动作或参数。

允许使用的规划 bucket 只有 7 个：

  1. scene
    • 来源：list_scenes.sh / trigger_scene.sh
  2. lights（灯光）
    • 来源：list_iot_devices.sh / control_iot.sh
  3. curtains（窗帘）
    • 来源：list_iot_devices.sh / control_iot.sh
  4. thermal comfort（体感舒适）
    • 来源：list_iot_devices.sh / control_iot.sh
    • 仅限用户明确说闷 / 热 / 冷时才使用
  5. display / playback device preparation（显示 / 播放设备）
    • 来源：list_iot_devices.sh / control_iot.sh
    • 包括：电视、投影、机顶盒、音量、信号源、模式切换
    • 这是观影模式最核心的特有 bucket
  6. smart-screen speech（智能屏播报）
    • 来源：list_devices.sh / speak.sh
  7. smart-screen assistant/media（智能屏助手 / 内容）
    • 来源：list_devices.sh / control_xiaodu.sh / push_resource.sh
    • 仅在用户明确指定内容时才进入

规划顺序：

  1. 先判断这次请求涉及哪些 bucket。
  2. 再检查当前环境真实支持哪些 bucket。
  3. 删除不支持的 bucket。
  4. 把剩余 bucket 排成最安全的观影执行顺序。
  5. 按 bucket 逐步执行，能做几步做几步。
  6. 同一条观影流程里的所有命令都必须串行执行。
    • 上一个命令返回后，才能发下一个命令。
    • 不要把 xiaodu 或 xiaodu-iot 的控制命令并发打出去。
    • 如果上一个命令失败，后面的命令直接继续执行，不要因为单点失败中断整条流程。
  7. 如果缺少继续执行所必需的信息，只问一个最小确认问题。
  8. 执行结束后，把用户的调整吸收为后续偏好。

偏好记忆与复用

把用户对观影流程的调整当成可复用偏好。 如果用户修正了默认设备、信号源、音量、灯光风格、是否继续内容层等，下次应优先沿用。

至少要支持沉淀这些偏好：

  • 观影默认设备
    • 电视 / 投影 / 智能屏
  • 观影默认房间
    • 客厅 / 卧室 / 默认房间
  • 默认信号源
    • HDMI / 电视主页 / 机顶盒
  • 默认音量
    • 小 / 中 / 大
  • 灯光风格
    • 全暗 / 柔和 / 留一点灯
  • 窗帘风格
    • 全关 / 半关
  • 是否自动进入内容层
    • 只做准备
    • 自动开平台
    • 自动切 HDMI
  • 默认避免控制的设备 / 房间
  • 确认风格
    • 先问再做
    • 只有一个明确目标时直接执行
  • 环境偏好
    • 偏凉 / 偏暖 / 不动空调

存储规则：

  • 默认不主动写入持久偏好文件。
  • 只有在用户明确表达“记住这个偏好 / 以后都这样 / 下次也这样”时，才允许持久化。
  • 小度 / 家庭场景的短中期偏好，优先写入 XIAODU_CONTEXT.md。
  • 只有在确实属于长期稳定偏好、且用户明确要求记住时，才写入 MEMORY.md。
  • 如果没有真的写入文件，就不要假装“已经记住”。

复用规则：

  • 下次执行前，先检查已有偏好能否直接解决设备或内容选择问题。
  • 如果已有偏好足够明确，就直接执行，不要重复问。
  • 如果已有偏好与当前环境或当前用户表达冲突，优先当前请求，并在执行后更新偏好。

标准执行流程

1）先确认依赖可用

只做这次请求真正需要的最小检查：

  1. 确认 skills/xiaodu-control-official 存在。
  2. 确认关键依赖脚本存在。
  3. 如果这次请求可能涉及 IoT，先读场景，再读 IoT 设备。
  4. 如果这次请求需要智能屏播报或设备确认，先解析出一个可用智能屏。

如果依赖 skill 不可用，就停止并明确说明此 skill 依赖 xiaodu-control-official。

2）优先尝试 scene-first

  1. 用 list_scenes.sh 读取现有场景。
  2. 优先寻找高匹配场景，例如：
    • 观影
    • 影院
    • 电影
    • 家庭影院
    • 看电影
  3. 如果找到高置信度场景，优先触发。
  4. 触发成功后，再补一句简短播报。

推荐观影模式播报口径：

  • 已经帮你把观影模式安排好了。
  • 房间已经调整好了，可以开始看了。
  • 观影模式已开启，准备好享受电影了。

如果 scene 触发失败，不能假装成功。

3）没有 scene 时，进入基于事实 bucket 的 fallback 规划

如果没有匹配 scene，不要直接退化成只说一句话。 而是继续基于事实 bucket 做结构化 fallback。

  1. 读取 IoT 设备。
  2. 只考虑这些 fallback bucket：
    • lights：把可用灯光调暗、关闭或调成更适合观影的亮度
    • curtains：如果有窗帘就关闭
    • thermal comfort：只有用户明确说闷 / 热 / 冷时，才考虑空调 / 风扇
    • display / playback device preparation：打开电视 / 投影、调音量、切信号源、切到观影模式
    • smart-screen speech：做一段简短确认播报
    • smart-screen assistant/media：只有用户明确指定内容时才进入
  3. IoT bucket 只允许使用同时满足以下条件的设备：
    • 真实存在于当前设备列表
    • 与目标房间相关，或已被用户明确指定
  4. 安全执行顺序：
    • scene（如果有）
    • lights
    • curtains
    • thermal comfort
    • display / playback device preparation
    • smart-screen speech
    • conditional smart-screen assistant/media
  5. 某个 bucket 没有合适设备就跳过，不影响其他 bucket。
  6. 如果多个目标都可能合理，只问一个最小确认问题。

关键原则： 没有 scene，不等于退出；而是进入基于事实能力的结构化 fallback。

4）把观影环境和设备准备纳入默认主流程

对于以下高层表达：

  • 开始观影模式
  • 我要看电影
  • 把房间调成适合看电影的状态
  • 准备看电影了

默认主流程应该是：

  1. 先做可做的观影环境调整
  2. 再做显示 / 播放设备准备（电视 / 投影 / 机顶盒 / 音量 / 信号源）
  3. 再做一句简短但明确的确认播报
  4. 只有用户明确指定内容时，才继续进入内容播放层

也就是说，产品默认理解不是：

  • 一上来就打开某个平台播放随机内容

而是：

先把房间和设备准备到“可以开始看”的状态，用户说要看了再继续内容层。

覆盖规则：

  • 如果用户明确指定了具体设备或内容，就按用户指定执行。
  • 如果已有偏好定义了环境 / 设备 / 信号源的顺序，就按偏好执行。
  • 如果当前环境不适合做某项环境调整，也不要直接退出，仍然要完成设备准备和确认播报，并尽可能补齐后续步骤。

5）通用观影模式实际调用链

对于这种高层请求：

开始观影模式

默认调用链应当是：

  1. bash ../xiaodu-control-official/scripts/list_scenes.sh --server xiaodu-iot
  2. 如果存在高置信度观影 scene：
    • bash ../xiaodu-control-official/scripts/trigger_scene.sh --scene-name "..." --server xiaodu-iot
  3. 否则：
    • bash ../xiaodu-control-official/scripts/list_iot_devices.sh --server xiaodu-iot
    • 如果有相关且可达的灯，用 bash ../xiaodu-control-official/scripts/control_iot.sh ... 调暗或关闭
    • 如果有窗帘，用 bash ../xiaodu-control-official/scripts/control_iot.sh ... 关闭
    • 如果有电视 / 投影 / 机顶盒 / 音量设备，做对应的准备动作
  4. bash ../xiaodu-control-official/scripts/list_devices.sh --server xiaodu
  5. bash ../xiaodu-control-official/scripts/speak.sh ...
  6. 如果用户明确指定了内容，继续：
    • bash ../xiaodu-control-official/scripts/control_xiaodu.sh --command "..." ...
    • 或进一步的 IoT 设备控制

这条链路能保证整条编排链是分层且显式的。 除非用户明确说要自动播放内容，否则不要跳过环境和设备准备阶段，直接进入内容播放。

内容层的默认边界

默认不做这些

  • 不默认替用户选具体电影
  • 不默认自动打开某个影视平台播放随机内容
  • 不默认搜索片单
  • 不默认把“观影模式”理解成“马上开播”

只有在用户明确指定时才做

  • 播电影 / 放《xxx》
  • 打开爱奇艺 / 腾讯视频 / 优酷 / B站
  • 切到 HDMI / 电视主页 / 机顶盒
  • 打开投影看电影
  • 打开电视开始播放

极简确认规则

需要确认的情况

  • 同时有电视和投影，用户没说用哪个
  • 同时有多个信号源都合理
  • 不问就容易误控（比如客厅电视和卧室电视都在线）

不需要确认的情况

  • 只有一个合理目标设备
  • 用户已经明确指定
  • 已有历史偏好

面向用户的汇报风格

面向用户时，优先给产品化、自然汇报，不要给技术动作日志。 一段好的自然汇报通常覆盖：

  1. 已经帮用户安排好了什么
  2. 现在正在发生什么
  3. 接下来用户还可以让系统继续做什么

而且要把真实已经成功的关键动作讲出来，不要把价值藏在后台。 如果灯光确实调暗了、窗帘确实关闭了、电视确实打开了、信号源确实切好了，就应该体现在用户可听见的汇报里。

示例：

  • 已经帮你把观影模式安排好了。
  • 我刚刚把灯光收暗了，房间也调整得更适合看电影，电视这边也已经准备好。
  • 现在已经可以开始看了，如果你想指定电影或者平台，我接着帮你切过去。

避免这样对用户说：

  • 我先执行了 list_scenes
  • 我调用了 control_iot
  • 我刚刚执行了脚本

失败处理

这个 skill 对局部失败应当有容错。 不要因为一个动作失败就让整个观影流程中断。

好的降级示例：

  • 没有 scene -> 自动改走设备 fallback
  • 投影失败 -> 继续做灯光、窗帘、电视等后续动作
  • 切信号源失败 -> 保持已准备好的设备状态，继续其他可做动作
  • 没有智能屏 -> 仍可完成 IoT 环境与设备动作
  • 某个属性不支持 -> 跳过这个属性继续后面动作
  • 内容层失败 -> 保持在“环境和设备已准备好”的状态，不假装电影已开始播放

为什么不能重做底层

除非必要，不要绕过 xiaodu-control-official，因为它已经：

  • 分清了 xiaodu 与 xiaodu-iot
  • 带有更安全的脚本约束
  • 定义了能力边界与 schema 预期
  • 让排障更容易聚焦在同一依赖层 续后面动作
  • 内容层失败 -> 保持在“环境和设备已准备好”的状态，不假装电影已开始播放

为什么不能重做底层

除非必要，不要绕过 xiaodu-control-official，因为它已经：

  • 分清了 xiaodu 与 xiaodu-iot
  • 带有更安全的脚本约束
  • 定义了能力边界与 schema 预期
  • 让排障更容易聚焦在同一依赖层

Comments

Loading comments...