{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Live Dashboard

从实时数据源构建自动更新的仪表盘。

Skill 元数据

参考：完整 SKILL.md

Live Dashboard

把一句话——"给我们的签证申请做个仪表盘，每天从邮件线程和案件状态网站更新"——变成一个持久、自刷新的状态页。用户描述想看什么；你来定义数据契约，构建一个自包含的 HTML 仪表盘，验证一次实时刷新，然后排上周期性节拍。

配置在前台运行一次；周期性刷新作为 cronjob 节拍运行。安装本 skill 会通过 /suggestions 提供一次每日全仪表盘扫描（frontmatter 蓝图）。

使用时机

• "给 <项目/流程> 做个仪表盘并保持更新。"
• "我想在一处看到 <交易 / 申请 / bug / 货运> 的状态。"
• "跨我的邮件和 <网站> 跟踪 <某事物>，告诉我它现在到哪了。"
• "给我看 <slug> 仪表盘。"（重渲染/预览已有的）
• 一个 cron 节拍为已有仪表盘触发（第 5-7 步）。

不要用于：一次性状态问题（直接答）、单个物品的价格/库存阈值（用 product-price-monitor）、公司新闻跟踪（用 competitor-news-monitor）。

前提条件

• 至少一个仪表盘要读取的数据源连接器：邮件/日历通过 himalaya 或 google-workspace，网站通过 web_extract 或 browser_navigate，本地文件通过 read_file。如果一个都没配，在写任何产物之前于第 1 步重新敲定数据源。
• cronjob 用于周期性节拍。
• 可选：desktop_preview 工具（Hermes 桌面应用会话）。当它在工具集里时，仪表盘渲染在应用内预览面板；否则把文件路径给用户。

流程——配置（前台，一次）

1. 定义仪表盘契约

从用户的那句话里敲定：仪表盘一句话的目的、被跟踪的实体（行）、每个实体的字段（列/指标）、"需要关注"意味着什么、每个字段从哪个源读取、以及刷新节奏。含糊的地方要问——跟踪错粒度的仪表盘一文不值。当仪表盘上每个字段都指名了它将从哪个源读取时，就算完成。

2. 用一次实时读取验证每个源

对每个源，现在在前台做一次有界读取：邮件/日历通过连接器 skill（himalaya、google-workspace），网站通过 web_extract 或 browser_navigate，本地文件通过 read_file。记录实际能取到什么——认证墙、缺失权限或空结果在这里暴露，而不是在第一次计划运行时。失败的源丢弃或替换。当每个字段的源都返回了真实数据、或已与用户明确重新商定，就算完成。

3. 构建仪表盘产物

在 Hermes 主目录的 dashboards/<slug>/ 下写两个文件（与 config.yaml 同一目录；不要假定固定位置）：

• dashboard.json——契约加当前状态：目的、实体、每字段值、每字段源 + 检索时间戳、一个 needs_attention 列表、以及一份变更日志（只追加，最新在前）。
• index.html——单个自包含 HTML 页（内联 CSS，无外部请求），渲染状态：带目的和最后更新时间的头部、顶部的"需要关注"区、实体表格、以及最近变更列表。每次刷新都从 dashboard.json 重新生成；绝不要手改 HTML 状态。

用第 2 步的读取填充两者，然后展示结果（第 8 步）。当页面渲染实时数据、且上面每个值在 dashboard.json 里都带检索时间戳时，就算完成。

4. 安排刷新

仅在第 3 步成功后，才安排节拍。如果 /suggestions 的每日全仪表盘扫描已经排上、且节奏合适，它会自动纳入这个仪表盘——说明这一点并停下。否则创建一个按仪表盘的任务，其 prompt 指名状态文件：

cronjob(action="create",
        schedule=<契约里的节奏，例如 "0 8 * * *">,
        prompt="加载 live-dashboard skill，为位于 <dashboards/<slug>/dashboard.json 的绝对路径> 的仪表盘运行刷新节拍。",
        deliver=<用户的接收目的地>)

选一个尊重源限流的节奏。当存在覆盖此仪表盘的任务、且其 prompt 指名了状态文件路径（或扫描）时，就算完成。

流程——节拍（每次计划运行）

5. 重读源并做 diff

加载 dashboard.json（扫描时：逐个加载每个 dashboards/*/dashboard.json），从指名的源重读每个字段，对存储的状态计算字段级 diff。源读取失败意味着未知状态：保留最后一个好值，用失败时间把该字段标记为陈旧，绝不用错误覆盖好数据。当每个字段都要么已更新、要么未变、要么被明确标记陈旧时，就算完成。

6. 更新状态并重渲染

把 diff 应用到 dashboard.json：更新值和时间戳，把实质性变更追加到变更日志，按契约的关注规则重算 needs_attention。从更新后的状态重新生成 index.html，然后展示结果（第 8 步）。当 JSON 和 HTML 一致、且本次运行的变更日志条目存在（或本次运行记录为无变更）时，就算完成。

7. 有实质变更才投递，否则保持静默

如果 diff 包含实质变更或新的需要关注项，投递一条简短摘要：变了什么、需要关注什么、仪表盘在哪。否则回复 [SILENT]——除非用户要周期性摘要，否则不要"仍在监视"的噪音。当投递与 diff 相符时，就算完成。

流程——展示仪表盘（每次构建或重渲染后，以及被要求时）

8. 渲染到用户能看到的地方

• 桌面/GUI 会话（工具集里有 desktop_preview）：desktop_preview(action="open", url=<index.html 绝对路径>, label=<仪表盘目的>)，让页面在聊天旁的预览面板里实时渲染；每次重渲染后重新打开，让面板显示新状态。
• 其他会话（CLI、messenger、没有 GUI 的 cron 节拍）：报告 index.html 的绝对路径，并在平台允许时主动打开。

当用户要么看到了渲染的页面、要么被告知它确切在哪时，就算完成。

常见陷阱

• 在验证源之前就先把页面做出来——认证失败就会在无人值守的运行上暴露。
• 用错误页或空读取覆盖最后已知的好值。
• 只把状态渲染进 HTML——dashboard.json 才是事实来源；HTML 只是投影。
• 每次刷新都告警，而不是只在实质变更时。
• 跟踪错粒度（用户按应用想，你却按线程记）。
• 硬编码 Hermes 主目录路径——从运行中的安装解析（持有 config.yaml 的目录），并把绝对路径写进 cron prompt。
• 在桌面会话之外调用 desktop_preview——它只在 GUI 会话的工具集里；回退到路径。

验证

•  每个仪表盘字段都指名了它的源，且每个源在安排前都通过了一次前台读取。
•  dashboard.json 和 index.html 存在且一致；每个值都带检索时间戳。
•  失败读取把字段标记陈旧，但不破坏最后已知好状态。
•  节拍只在实质变更时投递；无变更运行是 [SILENT]。
•  变更日志仅凭状态文件即可回放仪表盘历史。
•  仪表盘已在预览面板展示（桌面）或已报告其路径（其他）。