# Doubao Cron Scheduler

> 创建、查看、更新或删除定时任务：一次性提醒、周期任务、后台监控、多轮编辑已有任务、登录态/权限敏感任务。用于用户要求提醒我、稍后检查、持续关注、每天/每周/每小时运行、创建定时任务/提醒/监控、修改/暂停/删除刚才或已有定时任务。

- Skill: `ahang1598/doubao-cron-scheduler` (Agent Skill)
- Install (CLI): `npx skillmds add ahang1598/doubao-cron-scheduler`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/doubao-cron-scheduler/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ahang1598 (https://skillmd.com/u/ahang1598)
- Updated: 2026-08-19
- Page: https://skillmd.com/skills/ahang1598/doubao-cron-scheduler

---


# 定时任务Skill

## 核心原则

使用当前环境真实可用的定时工具创建或管理任务。不要只回复「我会提醒你」；只有定时工具调用成功，才算任务被创建。如果当前环境没有任何可调用的定时工具，明确说明无法创建，不要假装已创建。

---

## 可调度工具清单

| 工具名 | 用途 | 关键参数 |
|---|---|---|
| `create_cron_job` | 创建定时任务 | `title`、`query`、`schedule`、`schedule_type`(cron/at)、`enable`、`deadline`(可选) |
| `update_cron_job` | 更新已存在的定时任务 | `cron_job_id`、`patch`(可改 title/query/schedule/schedule_type/enable/deadline) |
| `delete_cron_job` | 删除定时任务 | `cron_job_id` |
| `get_cron_job` | 查询单个任务详情 | `cron_job_id` |
| `list_cron_jobs` | 按启用状态列出任务 | `enable`(true/false) |
| `get_current_time` | 获取实时世界时间 | `timezone`(IANA 或 UTC 偏移)、`format`、`include_multiple` |

## 锚定时间
当下游动作需要绑定到\"现在\"这个绝对时间锚点，或当用户使用「现在、今天、明天、今晚、本周、本月、最近、N 天后、几分钟后」等相对时间表述时，必须先调用`get_current_time`拿到用户时区下的实时时间，再做后续决策——典型场景：
**拆解用户需求**：把用户消息里的\"现在 / 今天 / 本周 / 本月 / 近 X 天 / 最近\"等相对时间表述，落到具体日期或时间窗口；
**做任务规划**：基于当前时间判断截止日期 / 优先级 / 任务窗口是否还来得及；
**调用下游工具时参数涉及实时时间**：例如查询最近 N 天的会议、设置 N 天后的提醒、按\"今天 / 本周\"过滤日历 / 邮件 / 待办等场景下，工具的时间参数必须用本工具返回的实时时间作为起点；
**时效性校验**：判断某个事件是否已过期 / 距离截止还剩多少时间。

- 用户提到城市或地区时映射到 IANA 时区；常见中国大陆场景用 `Asia/Shanghai`。
- 禁止凭模型自身记忆推断当前时间，避免时间锚点漂移。
- 存在歧义时，在最终回复中写清具体日期和时间。
- 定时任务按照创建时的时区执行。


### 时间解析与歧义澄清规则
- 当用户使用“明天早上 9 点”“今晚”“周一上午”“下周末”“3 小时后”这类自然语言时间表达创建或修改定时任务时，先调用 `get_current_time`，再结合当前时间与用户时区解析候选执行时间。如果该表达存在跨日、跨周、时区等导致的多种合理解释，且不同解释会得到不同的执行时间，必须先向用户澄清，不得直接创建任务。
- 凌晨时段特殊规则：当用户本地时间处于 0 点至 5 点，且用户提到“明天早上 / 明早 / 明天上午”等表达时，必须主动确认用户指的是“短时间后到来的早上”还是“自然日维度的明天早上”。候选项必须写成明确日期 + 星期 + 时间，不要继续只用“明天 / 后天”等相对表达。
- 澄清时：
  - 给出 2-3 个最可能候选时间。
  - 候选项必须写成明确日期 + 星期 + 时间。
  - 优先使用选择题式问法，降低用户理解和回复成本。
- 例如：用户在 2026-07-13 凌晨 3 点要求“明天早上 9 点提醒我吃饭”，回复示例如下：
  ```text
  我理解这里有两种可能，你说的“明天早上 9 点”是指：
  1. 2026-07-13（周一）09:00，也就是几个小时后
  2. 2026-07-14（周二）09:00，也就是自然日意义上的明天早上
  你希望我按哪个时间设置？
  ```
- 若用户明确表示“你直接决定”或“不用确认”，则选择最近一次未过期、且最符合日常语言直觉的时间执行，并在创建或更新前复述最终解析结果。
- 临近时间触发规则：如果解析出的首次执行时间晚于当前时间，必须明确告知用户“今天 / 当日就会触发”，不得误写成“明天开始”或“次日启动”。如果解析出的当日时间已经早于当前时间，才可以说明会顺延到下一次可执行时间，并写清具体日期和时间。**你告知用户的执行时间必须和你的实际执行时间保持一致**

### 创建或更新后的时间校验
- 调用 `create_cron_job` 或 `update_cron_job` 前，应记录基于当前时间解析出的“用户原始期望首次执行时间”
- `create_cron_job` 或 `update_cron_job` 调用成功后、回复用户前，必须再次调用 `get_current_time` 校验当前时间与首次执行时间的关系。
- 如果创建或更新耗时过长，导致用户原始期望的首次执行时间已经过去，不得继续按原定时间回复。必须向用户说明：
  - 因为创建复杂任务耗时较长，原定执行时间已经过去。
  - 所以我会立刻开始执行您的定时任务

---

## 解析并输出用户定时任务核心需求

- 每一次创建/更新定时任务的回复，**必须输出query和需求解析步骤**，再进入后续动作。这是强制要求，不可省略。
- 只有当用户的需求比较模糊，缺少任务时间、对象或动作等关键信息且无法推断时，才追问用户做需求澄清。


### query字段规范

- 单轮创建定时任务：用户在一轮对话中完成需求表达时，将用户该轮的**准确表述**列出，不做改写或缩略
- 多轮创建定时任务：用户跨多轮对话逐步补充需求时，输出**多轮总结后的完整需求**，不要丢失任何的细节，并抽取所有执行关键输入写入 `query`，包括但不限于：URL、文档 token、repo 路径、文件路径、账号/平台名称、筛选条件、时间范围、输出格式、验收标准，最后把分散在多轮里的执行关键输入合并到 `query`；不得因为链接、路径、ID 曾经出现在上文就省略。
- 单轮/多轮更新定时任务：
  - **保留原始**：原定时任务已确认的所有需求必须保留，不得覆盖。
  - **追加新增**：用户本轮新增的需求作为新条目追加到需求里。
  - **注意变更**：如果用户新需求与原需求有矛盾，以最新的需求为准。
  - **完整呈现**：每次输出都是当前最新版本的**完整需求**，而非仅显示增量 diff。
- 创建或更新前必须做一次“执行关键输入完整性检查”：如果任务依赖某个 URL、文档、页面、文件、仓库或外部资源，但当前无法在用户消息或上下文中确定其明确值，必须先追问用户；禁止自行猜测、补全或编造 URL。

**禁止**：遗漏任何一轮中用户已明确表达的需求；将多轮需求压缩成模糊概述。
**该字段默认存储**：任务名称、执行时间、任务目标、预期产出、必要的失败原因或授权提醒。开头写入“本次请求是由「{title}」定时任务到时触发的”，其中 `{title}` 必须与同次调用的 `title` 完全一致。

---

## 检查登录态与权限

在创建或更新任务前，告知用户定时任务判断任务是否依赖登录态、Cookie、私有页面、企业内网页、个人账号、二次验证或本地凭证等。

### 安全约束

- 不要把密码、Cookie、token 或一次性验证码写进 `query`。
- 不要假设当前浏览器登录态一定会在定时任务运行时可用。
- 任务运行时可能需要交互式登录、扫码、二次验证或用户确认，优先使用配置过的可复用登录态。
- 对内部文档、日历、邮件、工单、网页监控等权限敏感任务，写清需要访问的具体来源和最小必要范围。

### 需要登录时的引导

- **非常重要** 如果用户创建的定时任务需要用到浏览器，特别是需要登录网站进行操作的，应该在调用好创建定时任务后，直接用云端浏览器工具打开浏览器到对应的网站，并找到登录入口，让用户接管登录；如果当前页面还不是二维码、验证码或账号密码等可直接登录的入口，需要继续点击站内登录入口直到出现实际登录面板，例如微博不要只停留在普通登录页或首页。登录完成后保存的登录态将用于后续该定时任务的云端执行，接管完成后，整个创建定时任务的过程才算真正结束。
   - 如果判断任务依赖内外部平台/浏览器登录态，应优先执行对应登录 / 认证命令或打开登录入口；不要因可能需要用户配合而直接改用其他工具或查询路径。先使用open_url_in_browser工具检验用户在该平台是否已有登录态。如果没有，在创建定时任务**之前**告知用户，并提供可操作的登录入口——通过触发 interaction.request_action 工具，类型是browserControl，让用户完成登录。绝对禁止更换无需登录的平台、禁止关闭弹窗，禁止同时去搜别的平台，也禁止认为收集到的资料已足够而轻易放弃。必须让用户帮助完成登录
   - 当任务依赖 CLI登录态时，应优先执行对应登录 / 认证命令或打开登录入口；不要因可能需要用户配合而直接改用其他工具或查询路径。先使用bash工具检验是否已经安装并具备该cli的登录态。如果没有，在创建定时任务**之前**告知用户，并提供可操作的登录入口——通过 soft link 触发 interaction 工具，类型是browserControl，让用户完成登录。绝对禁止更换无需登录的平台、禁止关闭弹窗，禁止同时去搜别的平台，也禁止认为收集到的资料已足够而轻易放弃。必须让用户帮助完成登录
- 如果定时任务执行一段时间后，登录态丢失，再重新引导用户登录。

### 登录成功反馈

用户完成登录后：
1. 保存 cookie 到云环境。
2. 向用户反馈：`✅ 登录成功，cookie 已保存。定时任务「{title}」现在可以正常运行了。`
3. 继续执行定时任务创建/更新流程。

### 登录失败处理

当定时任务触发执行时检测到登录态丢失（cookie 过期/无效/不存在），**必须**：

1. **明确告知失败原因**：
   ```text
   ⚠️ 定时任务「{title}」执行失败。
   
   失败原因：登录状态丢失（cookie 已过期或不存在），导致无法完成目标任务。
   ```

2. **提供重新登录入口**：

3. **不在用户未重新登录的情况下反复重试**，避免无效执行。

### 登录态检查清单

| 检查项 | 通过条件 |
|---|---|
| 是否已识别任务需要登录态？ | 任务涉及认证平台/API/页面 |
| 是否已告知用户需要登录？ | 回复中包含登录提示 |
| 是否提供了 soft link？ | 回复中包含具体的链接 |
| 用户是否已完成登录？ | 收到 cookie 保存成功反馈 |
| 是否在创建任务前确认登录态？ | 登录成功后才创建/启用任务 |
| query 中是否避免写入敏感凭证？ | 无密码/cookie/token/验证码 |

---

## 产品规则
1. 定时任务执行时用户触发时不一定在线，因此执行过程中非必要不要调用 askhuman 或任何需要向用户追问/确认的工具；应基于已有信息和可用工具独立完成任务，如确实缺少必要信息则在最终回复中说明无法完成的原因。特别的：但如果在执行中发现没有登录态，可以请用户协助登录。


---

## 执行操作

根据用户意图判断操作类型：新建、修改、删除或查询。

### 创建定时任务

使用 `create_cron_job` 创建新任务。

**参数填写**：

| 参数 | 规则 |
|---|---|
| `title` | 短标题，如「提醒吃饭」「检查价格变化」「每周测试报告」 |
| `query` | 写任务触发时真正要执行的事，应在这里描述该任务的具体目标、要求和输出期望。 |
| `schedule_type` | 一次性任务用 `at`；周期性任务用 `cron` |
| `schedule` | 必须匹配 `schedule_type` |
| `enable` | 用户未要求暂停时必须为 `true` |
| `deadline` | 只有用户明确要求周期任务在某个截止时间后停止时才填写；`schedule_type: "at"` 时不要填写 |


**时间表达式规范**：
- `at` 表达式使用 Linux at 可识别格式：`now + 1 minute`、`now + 2 hours`、`tomorrow 09:15`、`2026-04-12 19:13`。
- 不要把 `in 1 minute` 写成 at 表达式；用户说「一分钟后」时写 `now + 1 minute`。
- 周期任务用标准 Linux cron 表达式。
- 除非用户明确且强烈要求，否则不要默认使用整点，尤其不要默认早上 9 点。

**创建成功后的回复**：
- 告知已创建的任务名称。
- 告知它会在什么时候提醒或开始执行，并使用创建成功后再次调用 `get_current_time` 得到的时间做校验。
- 如果首次执行时间晚于创建后校验时间，必须明确说明当日是否会触发：当首次执行日期是今天时，写清“今天 {具体时间} 会触发”；当首次执行日期不是今天时，写清具体日期、星期和时间。
- 如果创建耗时导致用户原始期望时间已经过去，必须说明"因为创建复杂任务耗时较长，原定执行时间已经过去,所以我会立刻开始执行您的定时任务"
- 复杂任务说明 AI 会怎么做：关键步骤、会检查或处理哪些信息、预期产出。这里必须参考 query 字段记录下的所有用户要求，不能忽略任何细节。
- 复杂任务通常会比设定时间晚几分钟完成，因为任务触发后仍需要执行时间。
- 不要向用户展示 `cron_job_id` 或其他任务 ID，除非用户明确询问或后续管理必须让用户知道。

### 修改定时任务

使用 `update_cron_job` 更新已存在任务。

**参数填写**：

| 参数 | 规则 |
|---|---|
| `cron_job_id` | 已存在的定时任务 ID，从 `get_cron_job` 或 `list_cron_jobs` 获取 |
| `query` | 写任务触发时真正要执行的事，应在这里描述该任务的具体目标、要求和输出期望。 |
| `schedule_type` | 一次性任务用 `at`；周期性任务用 `cron` |
| `schedule` | 必须匹配 `schedule_type` |
| `enable` | 用户未要求暂停时必须为 `true` |
| `deadline` | 只有用户明确要求周期任务在某个截止时间后停止时才填写；`schedule_type: "at"` 时不要填写 |

**修改成功后的回复**：
- 告知已更新的任务名称。
- 告知它会在什么时候提醒或开始执行，并使用更新成功后再次调用 `get_current_time` 得到的时间做校验。
- 如果首次执行时间晚于更新后校验时间，必须明确说明当日是否会触发：当首次执行日期是今天时，写清“今天 {具体时间} 会触发”；当首次执行日期不是今天时，写清具体日期、星期和时间。
- 如果更新耗时导致用户原始期望时间已经过去，必须说明"因为更新复杂任务耗时较长，原定执行时间已经过去,所以我会立刻开始执行您的定时任务"
- 复杂任务说明 AI 会怎么做：关键步骤、会检查或处理哪些信息、预期产出。
- 不要向用户展示 `cron_job_id` 或其他任务 ID，除非用户明确询问或后续管理必须让用户知道。

### 删除定时任务

使用 `delete_cron_job` 删除已存在任务。

**参数填写**：

| 参数 | 规则 |
|---|---|
| `cron_job_id` | 已存在的定时任务 ID，从 `get_cron_job` 或 `list_cron_jobs` 获取 |

**删除成功后的回复**：
- 告知已删除的任务名称。
- 告知它已从系统中移除。
- 不要向用户展示 `cron_job_id` 或其他任务 ID，除非用户明确询问或后续管理必须让用户知道。

### 查询定时任务

使用 `get_cron_job` 查询已存在任务。

**参数填写**：

| 参数 | 规则 |
|---|---|
| `cron_job_id` | 已存在的定时任务 ID，从 `get_cron_job` 或 `list_cron_jobs` 获取 |

**查询成功后的回复**：
- 告知任务的详细信息，包括标题、查询、时间表达式、是否启用、截止时间等。
- 不要向用户展示 `cron_job_id` 或其他任务 ID，除非用户明确询问或后续管理必须让用户知道。

使用 `list_cron_jobs` 查询所有启用的定时任务。

**参数填写**：

| 参数 | 规则 |
|---|---|
| `enable` | 是否启用，默认 `true` |

**查询成功后的回复**：
- 告知所有启用的定时任务的 ID、标题、查询、时间表达式、是否启用、截止时间等。
- 不要向用户展示 `cron_job_id` 或其他任务 ID，除非用户明确询问或后续管理必须让用户知道。

## 回复用户

根据操作结果回复


## 常见映射举例

- 「20 分钟后提醒我休息一下」→ `at` + `now + 20 minutes`
- 「每个工作日上午提醒我规划当天任务」→ `cron`，工作日 cron 表达式
- 「每周一检查这个 repo 并总结失败测试」→ 周期任务，写清工作区、测试命令、输出格式和失败汇报方式
- 「持续关注这个页面，价格变化时告诉我」→ 周期监控，写清 URL、登录态要求、对比标准和通知阈值
- 「把刚才的提醒改到明天 10 点」→ 多轮编辑，先指代解析定位已有任务，再输出合并需求，用户确认后 update 修改时间
- 「暂停/恢复/删除我的提醒」→ 定位已有任务后 update `enable` 或 delete

---

## 最小确认原则

- 缺少必要时间、任务内容、目标对象或权限前提时再追问。
- 能通过当前上下文、工具详情或已有任务列表确定时，直接执行。
- 对可能造成重复、误删、错误账号访问或登录态失败的情况，先确认关键点。
- 多轮修改同一 topic 时，必须输出完整合并需求后才执行 update。

---

## 注意事项

1. **时间锚定**：涉及相对时间时，必须先调用 `get_current_time`，禁止凭模型记忆推断。
2. **需求不遗漏**：无论单轮还是多轮，必须覆盖用户已表达的所有需求点。
3. **增量不覆盖**：多轮修改时，原需求保留，新需求追加，如果需求之间无矛盾则不覆盖已有条目，如果有矛盾则以最新的需求为准。
4. **登录态优先**：涉及登录态的任务，先确保登录成功再创建/启用；query 中不写入敏感凭证。
5. **不展示 ID**：除非用户需要 ID 来管理任务，否则不在回复中展示 `cron_job_id`。
6. **真实调用**：不要只回复「我会提醒你」；只有定时工具调用成功才算任务被创建。