Aloudata CAN SKILLS - scheduled-report
by @jackyujun
将当前对话中已完成的分析流程，提取并固化为定时执行的任务（周报/月报/日巡检等）。本 Skill 是一个纯粹的**编排层**——它不负责定义"怎么分析"，只负责"把你刚才做的分析录下来，变成能定时重放的任务"。 触发场景包括但不限于：用户提到"定时报告""定时分析""定期执行""自动报告""把这个分析变成周报""...
clawhub install scheduled-report📖 About This Skill
name: scheduled-report description: | 将当前对话中已完成的分析流程，提取并固化为定时执行的任务（周报/月报/日巡检等）。本 Skill 是一个纯粹的编排层——它不负责定义"怎么分析"，只负责"把你刚才做的分析录下来，变成能定时重放的任务"。 触发场景包括但不限于：用户提到"定时报告""定时分析""定期执行""自动报告""把这个分析变成周报""每周跑一次""定期监控""scheduled report""自动化分析""固化为报告""保存为定时任务""每月生成报告""定期推送""自动跑这个分析""帮我做成周报""以后每周都这么分析""定时汇报""创建定时分析""定期巡检""以后每天都帮我检查一下"，或用户在对话中完成分析后表达希望定期重复执行的意图时，都应使用此 Skill。 触发判定关键：用户表达中必须包含"定时/定期/每X/以后都"等表示重复执行的时间意图。仅说"月报""周报"不触发本 Skill（→ 触发 analysis-report）；说"每月出一份月报""以后每周都跑"才触发本 Skill。区分方式： - "出一份月报" → analysis-report（一次性，现在就要） - "以后每月都出月报" → scheduled-report（定时重放） - "帮我监控一下销售额" → anomaly-detection（先做一次分析） - "帮我每天监控销售额" → scheduled-report（有"每天"=定时意图，但需先引导完成一轮分析） 前提条件：用户需要先在对话中完成一轮分析（通过 metric-query、metric-attribution、dataset-detail-query 等 Skill），本 Skill 才能提取分析逻辑并固化为定时任务。如果对话中没有分析历史，应先引导用户完成分析，再触发本 Skill。
定时任务编排 Skill
执行模式
> 如果你不确定自己属于哪个类别，请按"标准模型"模式执行。
定位
本 Skill 是一个编排层，职责是：
1. 录制：从当前对话中提取用户已完成的分析步骤
2. 打包：将分析步骤组装为自包含的、可独立执行的 prompt
3. 调度：通过 openclaw cron add 创建定时任务
它不负责定义分析逻辑本身。异常检测怎么做、归因怎么跑、阈值怎么设——这些是分析类 Skill（metric-query、metric-attribution 等）的职责。本 Skill 只是忠实地把对话中发生过的分析过程"录"下来。
与分析类 Skill 的关系
用户在对话中完成分析（分析类 Skill 各司其职）
│
│ metric-query → 查指标数据
│ metric-attribution → 归因分析
│ dataset-detail-query → 明细查询
│
▼
用户说"帮我做成定时任务"
│
▼
本 Skill 介入（编排层）
│
│ Step 1: 提取对话中的分析步骤
│ Step 2: 整理为配置大纲
│ Step 3: 用户确认
│ Step 4: 组装自包含 Prompt
│ Step 5: openclaw cron add
│
▼
定时任务创建完成，未来按 cron 自动重放
Step 1：提取对话中的分析步骤
回顾当前对话的全部历史，原样提取用户实际执行过的每一个分析步骤。
1.1 需要提取的信息
逐条扫描对话历史，找到所有执行过的分析操作，记录：
指标查询（metric-query）：
归因分析（metric-attribution）：
明细查询（dataset-detail-query）：
用户的分析判断：
1.2 提取原则
忠实记录，不添加：只提取对话中实际做过的事，不自行添加用户没要求的分析步骤。
保留精确参数：metricName、dimName、filters 值必须原样保留，不能用展示名替换代码名。
标注时间语义：记录每个 timeConstraint 的业务含义（"上月""近30天"），后续需要将绝对时间转换为 NOW() 相对时间。
Step 2：整理为配置大纲
将提取的步骤整理为结构化的配置，展示给用户确认。
2.1 配置大纲模板
📋 定时任务配置草案任务名称：[基于分析内容自动命名，如"销售业绩周报"、"渠道异常日巡检"]
📊 分析步骤：
1. [步骤1描述]（如：查询各渠道销售额及环比变化）
2. [步骤2描述]（如：对销售额做归因分析，下钻到品牌维度）
3. [步骤3描述]（如：检查异常品牌的明细数据）
...
⏰ 建议执行频率：[频率]
建议执行时间：[时间]
📄 输出格式：[与对话中的分析输出格式一致]
2.2 执行频率推荐
从对话中的 timeConstraint 推断合理的执行频率：
| 对话中的时间范围 | 推荐频率 | 推荐 cron |
|---------------|---------|----------|
| 上周、近7天 | 周报 / 每周一 | 0 9 * * 1 |
| 上月、近30天 | 月报 / 每月1日 | 0 9 1 * * |
| 昨天、近N天 | 日报 / 每天 | 0 9 * * * |
| 上季度 | 季报 / 每季度首月1日 | 0 9 1 1,4,7,10 * |
| 用户明确说了频率 | 按用户要求 | 对应 cron |
2.3 时间范围转换
对话中的绝对时间必须转换为 NOW() 相对时间：
"2025-12-01" → DATEADD(DateTrunc(NOW(), "MONTH"), -1, "MONTH")（上月）"2025-12-15" → DATEADD(DateTrunc(NOW(), "DAY"), -1, "DAY")（昨天）Step 3：用户确认/调整
将配置草案展示给用户，通过对话确认。
以上是我根据咱们刚才的分析整理出的定时任务配置。请确认：
1. 分析步骤是否完整？需要增减吗？
2. 执行频率建议为 {频率}，合适吗？
3. 还有其他需要调整的地方吗？
没问题的话我就创建定时任务了。
处理原则：
Step 4：组装 Prompt
将确认后的配置生成一个完全自包含的 prompt，用于 openclaw cron add --agent-turn。
4.1 核心原则
完全自包含：这个 prompt 将在未来的独立会话中执行，无法访问当前对话。所有信息必须写入 prompt。
忠实重放：prompt 的分析步骤应与用户在对话中做过的步骤一一对应，不添加额外步骤。
使用相对时间：所有 timeConstraint 中的绝对日期必须替换为 NOW() 表达。
委派 metric-query Skill：所有数据查询通过 metric-query Skill 执行，不直接调用 Gateway API，确保查询逻辑的可维护性和一致性。
4.2 Prompt 模板
你是一个数据分析助手，负责执行定期分析任务。请严格按照以下步骤执行。任务信息
任务名称：{名称}
执行周期：{周报/月报/日报}
分析时间范围：{相对时间描述} 执行步骤
步骤 1：{步骤描述}
{该步骤的完整指令——直接从对话中提取，替换时间为 NOW()}使用 metric-query Skill 执行以下查询：
{查询意图的自然语言描述}
查询参数参考：
{完整请求体 JSON，timeConstraint 使用 NOW()}
{对查询结果的分析指令——与用户在对话中的分析方式一致}
步骤 2：{下一步骤}
{同上格式}...
错误处理
如果某个查询返回错误，记录错误信息并继续执行下一步
如果数据为空，在输出中标注"本期暂无数据" 输出格式
{与用户在对话中看到的分析输出格式一致}生成报告后保存为 Markdown 文件，文件名格式：{任务名称}_{YYYY-MM-DD}.md
4.3 Prompt 自检清单
组装完成后逐项检查：
1. ✅ 所有 timeConstraint 使用 NOW()，无硬编码日期 2. ✅ 所有 metricName / dimName 使用代码名称，非展示名 3. ✅ metricDefinitions 中每个 key 都在 metrics 数组中 4. ✅ 所有数据查询通过 metric-query Skill 执行，未直接调用 Gateway API 5. ✅ prompt 中无"刚才""上面提到的"等依赖对话上下文的表达 6. ✅ 分析步骤与用户在对话中实际做过的步骤一致，无凭空添加
Step 5：创建定时任务
5.1 命令格式
openclaw cron add --name "<任务名称>" --cron "" --agent-turn ""
所有定时分析任务都属于复杂任务，必须使用 --agent-turn（触发 Agent 多步执行），不可使用 --system-event（仅适用于简短一次性指令）。
5.2 参数映射
| 参数 | 取值 |
|------|------|
| --name | Step 2 中确认的任务名称 |
| --cron | Step 2 中确认的执行频率对应的 cron 表达式 |
| --agent-turn | Step 4 生成的完整 prompt |
| --enabled | 默认不传（自动启用），用户要求暂不启用时传 false |
5.3 Prompt 过长时的处理
如果 prompt 过长导致命令行传参困难，先将 prompt 写入临时文件再传入：
# 先写入文件
cat > /tmp/task_prompt.txt << 'PROMPT_EOF'
{完整 prompt 内容}
PROMPT_EOF再创建任务
openclaw cron add --name "销售业绩周报" --cron "0 9 * * 1" --agent-turn "$(cat /tmp/task_prompt.txt)"
5.4 创建后确认
✅ 定时任务已创建！📋 任务名称：{name}
📝 任务内容：{简要描述，1-2句话}
⏰ 执行频率：{频率描述}
📌 状态：已启用
管理命令：
查看任务：openclaw cron list
暂停任务：openclaw cron disable --name "{name}"
删除任务：openclaw cron remove --name "{name}"
边界场景处理
对话中没有分析历史（重要——高频场景）
用户在没有前置分析的情况下直接下达定时任务需求，如"帮我每周监控一下库存的健康状况""帮我做个销售周报"。
处理原则：主动引导用户完成一轮分析，分析完成后自动衔接定时任务创建，整个过程是连贯的，不需要用户再说一遍"帮我做成定时任务"。
流程如下：
用户："帮我每周监控一下库存的健康状况"
│
▼
本 Skill 触发 → Step 1 扫描对话 → 无分析历史
│
▼
进入"引导分析"模式：
│
├→ 1. 先记住用户的定时任务意图（"每周""监控""库存健康"）
│
├→ 2. 引导用户明确分析内容：
│ "我来帮您搭建这个定时巡检任务。
│ 我们先一起确定要监控哪些指标、怎么算异常，
│ 我帮您跑一遍看看效果，然后直接创建定时任务。"
│
├→ 3. 通过 Gateway 搜索相关指标，展示给用户选择
│ （调用 metric-query 等分析 Skill 的能力）
│
├→ 4. 用户选定后，实际执行一轮完整分析
│ - 查数据、看结果
│ - 和用户讨论什么算异常、关注哪些维度
│ - 按用户要求调整分析逻辑
│
├→ 5. 分析完成后，对话中已有完整的分析记录
│
▼
自动衔接 Step 1-5（不需要用户再说一遍）：
"好的，刚才的分析流程我已经整理好了。确认一下配置，
我就帮您创建每周自动执行的任务。"
关键细节：
对话中有多个不相关的分析
1. 列出检测到的分析主题 2. 让用户选择：全部放入一个任务？还是拆成多个任务？
时间范围不统一
1. 标注每个步骤的时间范围 2. 让用户确认是否统一调整
用户想增加对话中没做过的步骤
用户在 Step 3 确认时说"再加一个XX分析"：
1. 不要凭空编造分析步骤 2. 引导用户先在当前对话中把这个分析做一遍 3. 做完后更新配置，重新走 Step 2-3
常见错误模式
❌ Prompt 中使用了绝对日期："2026-03-01" 这样的硬编码日期必须替换为 NOW() 相对时间。
❌ Prompt 引用了当前对话上下文：写了"如上所述""刚才分析的"。未来执行时没有当前对话，prompt 必须自包含。
❌ 未委派 metric-query Skill 查数，而是直接在 prompt 中写了 API 调用：所有 Gateway API 调用都应通过 metric-query Skill 执行，prompt 中应该是查询意图和参数说明，而不是 curl 命令。
❌ 没让用户确认就创建：跳过 Step 3 直接创建任务。
❌ 指标名/维度名不精确：使用展示名而非 metricName / dimName。
❌ 临时指标未注册：metricDefinitions 的 key 未出现在 metrics 数组中。
❌ 使用 --system-event 而非 --agent-turn：分析任务是多步复杂任务，必须用 --agent-turn。
❌ 凭空添加分析步骤：用户只在对话中做了查询和环比分析，prompt 里却额外加了归因分析、趋势预测等用户没做过的步骤。本 Skill 的职责是"录制重放"，不是"自作主张扩展"。
❌ Prompt 转义错误：--agent-turn 的 prompt 含双引号等特殊字符未正确转义。建议将 prompt 先写入文件再用 $(cat file) 传入。