Skill: jackyujun/scheduled-report (version 1.0.0)

--- 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 ## 执行模式 - **强模型**（Claude Opus/Sonnet, GPT-4o/5）：遵循"原则"段落，自行决定实现细节 - **标准模型**（Qwen, DeepSeek, Llama）：严格按"模板"段落执行，使用提供的代码块，不要自行改写 > 如果你不确定自己属于哪个类别，请按"标准模型"模式执行。 ## 定位 本 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）**： - 实际查询的请求参数（metrics、dimensions、timeConstraint、filters 等——这是未来重放的基础） - metrics 数组中的指标名 - dimensions、filters、resultFilters、timeConstraint - metricDefinitions（如有） - 用户对查询结果的解读和关注点 **归因分析（metric-attribution）**： - 归因的目标指标和对比基准 - 因子拆解公式 - 下钻维度和路径 - 执行过的全部查询 **明细查询（dataset-detail-query）**： - 数据集名称、查询字段、筛选排序条件 **用户的分析判断**： - 用户对数据的结论（"这个渠道有问题""这几个品牌表现不错"） - 用户在对话中设定的阈值或标准（"跌超过 15% 就算异常"） - 用户要求的输出格式偏好 ### 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")`（昨天） - 如果对话中已经用了 NOW()，直接保留 --- ## Step 3：用户确认/调整 将配置草案展示给用户，通过对话确认。 ``` 以上是我根据咱们刚才的分析整理出的定时任务配置。 请确认： 1. 分析步骤是否完整？需要增减吗？ 2. 执行频率建议为 {频率}，合适吗？ 3. 还有其他需要调整的地方吗？ 没问题的话我就创建定时任务了。 ``` 处理原则： - 用户说"可以""就按刚才的来" → 全部确认，进入 Step 4 - 用户提出修改 → 调整后重新展示 - 用户要求增加新步骤 → **引导用户先在当前对话中把这个分析做一遍**，做完后再提取纳入配置。不要凭空编造分析步骤 --- ## 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 命令格式 ```bash openclaw cron add --name "<任务名称>" --cron "<Cron表达式>" --agent-turn "<prompt>" ``` 所有定时分析任务都属于**复杂任务**，必须使用 `--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 写入临时文件再传入： ```bash # 先写入文件 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（不需要用户再说一遍）： "好的，刚才的分析流程我已经整理好了。确认一下配置， 我就帮您创建每周自动执行的任务。" ``` **关键细节**： - 在引导分析的过程中，始终记住用户的最终目的是创建定时任务，不要做完分析就结束了 - 引导分析时调用的是其他分析 Skill（metric-query、metric-attribution 等）的能力，本 Skill 不自行实现分析逻辑 - 分析完成后，**自动**进入 Step 1 提取流程，不要等用户再次触发 - 从用户原始需求中提取的信息（频率"每周"、领域"库存健康"）在后续 Step 2 中直接使用，不需要重复询问 ### 对话中有多个不相关的分析 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)` 传入。


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)