scheduled-report

将当前对话中已完成的分析流程,提取并固化为定时执行的任务(周报/月报/日巡检等)。本 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。**

Safety Notice

This listing is from the official public ClawHub registry. Review SKILL.md and referenced scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "scheduled-report" with this command: npx skills add jackyujun/scheduled-report

定时任务编排 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 命令格式

openclaw cron add --name "<任务名称>" --cron "<Cron表达式>" --agent-turn "<prompt>"

所有定时分析任务都属于复杂任务,必须使用 --agent-turn(触发 Agent 多步执行),不可使用 --system-event(仅适用于简短一次性指令)。

5.2 参数映射

参数取值
--nameStep 2 中确认的任务名称
--cronStep 2 中确认的执行频率对应的 cron 表达式
--agent-turnStep 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(不需要用户再说一遍):
  "好的,刚才的分析流程我已经整理好了。确认一下配置,
   我就帮您创建每周自动执行的任务。"

关键细节

  • 在引导分析的过程中,始终记住用户的最终目的是创建定时任务,不要做完分析就结束了
  • 引导分析时调用的是其他分析 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) 传入。

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

General

TOKEN SOP

自动保存并本地调用已执行任务,避免重复消耗Token,实现离线秒级响应,提升效率与节省费用。

Registry SourceRecently Updated
General

Facebook-poster

Generuoja kasdienius įtraukiamus Facebook įrašus lietuvių kalba, kad sujungtų Qvicker.lt vartotojus su vietiniais paslaugų meistrais.

Registry SourceRecently Updated
General

TOKEN SOP

自动缓存并复用本地成功工作流,优先本地执行节省Token,支持断网使用和云端备份共享。

Registry SourceRecently Updated
General

generate-personal-brand-ad-creative-brief

Plan campaign visuals and hooks for personal brand promotions. Use when working on paid campaign planning for thought leaders, coaches, personal brand...

Registry SourceRecently Updated