Doubao Cron Scheduler

---
name: doubao-cron-scheduler
description: 创建、查看、更新或删除定时任务，包括一次性提醒、周期任务、复杂日历规则、后台监控和多轮编辑。用于用户要求提醒、持续关注、按小时/日/周/月/年运行或管理已有任务。
---

# 定时任务Skill

## 核心原则

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

---

## 可调度工具清单

| 工具名 | 用途 | 关键参数 |
|---|---|---|
| `create_cron_job` | 创建定时任务 | `title`、`query`、`schedule`、`schedule_type`(cron/at/rrule)、`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` |

## 工具返回约定

- `create_cron_job` 和 `update_cron_job` 返回创建或更新后的任务详情，包括
  `cron_job_id`、`title`、`schedule_type`、`schedule`、`status`、
  `last_run_time`、`deadline`（如有）、`next_trigger_time`、`timezone` 和运行环境；
  不返回 `query`。
- `list_cron_jobs` 返回同一组任务详情字段，但不返回 `query`。需要查看某个任务的
  `query` 时，使用 `get_cron_job`。
- `get_cron_job` 在任务详情后单独返回完整的原始 `query`。只更新时间、标题或启用状态时
  仍应省略 `patch.query`，由服务端保留原值。

## 锚定时间
当下游动作需要绑定到\"现在\"这个绝对时间锚点，或当用户使用「现在、今天、明天、今晚、本周、本月、最近、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/验证码 |


---

## 执行操作

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

### 单任务创建原则

- 除非用户明确要求创建多个彼此独立的定时任务，否则优先只创建一个定时任务。
- 创建前先判断用户要求的全部执行时间能否由一条标准 cron 准确表达；不能时，再判断能否由一条 RRULE 准确表达。只要其中一种可以准确表达，就只调用一次 `create_cron_job`。
- 多个执行时间的小时与分钟不能由一条 cron 保持配对关系时，不要直接判定需要拆分。继续尝试用 RRULE 的 `BYHOUR`、`BYMINUTE` 生成当前 `FREQ` 周期内的完整候选集合，再用 `BYSETPOS` 按时间升序选出目标位置；只有最终集合与用户要求完全一致时才可使用。
- 如果一条 cron 和一条 RRULE 都无法准确表达，必须先向用户说明需要拆分，并询问是否创建两个定时任务；未经用户明确确认，不得多次调用 `create_cron_job`。

### deadline 使用规则

- `cron`：支持 `deadline`。只有用户明确要求周期任务在某个日期时间后停止时才传；没有明确截止要求时不要传。
- `at`：不要传 `deadline`，一次性执行时间由 `schedule` 决定。
- `rrule`：
  - 包含 `COUNT` 或 `UNTIL` 时不要传 `deadline`，终止条件以 RRULE 为准。
  - 不包含 `COUNT`/`UNTIL`，且用户明确要求独立截止时间时，可以传 `deadline`。
- `deadline` 使用任务时区下的 `YYYY-MM-DD HH:mm:ss` 格式。

### 创建定时任务

使用 `create_cron_job` 创建新任务。

**参数填写**：

| 参数 | 规则 |
|---|---|
| `title` | 短标题，如「提醒吃饭」「检查价格变化」「每周测试报告」 |
| `query` | 写任务触发时真正要执行的事，应在这里描述该任务的具体目标、要求和输出期望。 |
| `schedule_type` | 一次性任务用 `at`；简单周期任务用 `cron`；复杂日历周期、带次数或结束时间的周期任务用 `rrule` |
| `schedule` | 必须匹配 `schedule_type` |
| `enable` | 用户未要求暂停时必须为 `true` |
| `deadline` | 按上方“deadline 使用规则”填写 |


**时间表达式规范**：
- `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 表达式。
- 复杂日历周期、需要保持间隔相位或使用 `COUNT`/`UNTIL` 的任务使用 RRULE。
- 除非用户明确且强烈要求，否则不要默认使用整点，尤其不要默认早上 9 点。

### RRULE 调度规则

#### 选择 RRULE

以下场景使用 `schedule_type: "rrule"`：

- 每两周、每三个月等需要保持 `INTERVAL` 相位的周期。
- 每月最后一个工作日、每年第几个星期等复杂日历规则。
- 用户要求执行固定次数，使用 `COUNT`。
- 用户要求在某个本地日期时间后停止，使用 `UNTIL`。

简单的每小时、每天、每周任务如果不需要上述能力，继续优先使用 cron。

#### schedule 格式

RRULE 的 `schedule` 必须一次性传入完整的两行文本：

```text
DTSTART:YYYYMMDDTHHMMSS
RRULE:FREQ=...
```

- 第一行只能是 `DTSTART:`，第二行只能是 `RRULE:`，不得增加第三行。
- `DTSTART` 是任务时区下的本地墙钟时间，也是周期相位锚点。
- `schedule` 中禁止出现 `TZID`、结尾 `Z` 或 `+08:00` 等 UTC offset。
- 不要向 `create_cron_job` 或 `update_cron_job` 传 timezone；任务时区由当前运行环境注入。
- 必须保留 `RRULE:` 前缀，不要只传 `FREQ=...`。
- `COUNT` 与 `UNTIL` 互斥；`COUNT` 必须在 1 到 1000 之间。
- `DTSTART` 和 `UNTIL` 均只支持分钟精度：格式仍为 `YYYYMMDDTHHMMSS`，但最后两位秒必须固定为 `00`。
- `UNTIL` 使用本地基本格式，例如 `UNTIL=20261231T235900`；不得省略秒字段，也不得带 `Z` 或 offset。
- 不生成 `BYSECOND`、`WKST` 或其他未明确支持的扩展字段。

#### deadline 规则

- RRULE 包含 `COUNT` 或 `UNTIL` 时，不要传 `deadline`。
- RRULE 不含终止条件，且用户明确要求独立截止时间时，才允许传 `deadline`。
- 用户要求“执行 N 次”时使用 `COUNT=N`，不要自行换算 deadline。
- 用户要求“运行到某日某时”时优先使用 `UNTIL`，不要同时再传 deadline。

#### RRULE 示例

每天 09:30 执行 10 次：

```text
DTSTART:20260917T093000
RRULE:FREQ=DAILY;COUNT=10
```

从指定星期开始，每两周的周二、周四 10:30 执行：

```text
DTSTART:20260917T103000
RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=TU,TH
```

每月最后一个工作日 18:00 执行：

```text
DTSTART:20260930T180000
RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
```

每天 11:00、14:30 执行：

```text
DTSTART:20260901T110000
RRULE:FREQ=DAILY;BYSETPOS=1,4;BYHOUR=11,14;BYMINUTE=0,30
```

上例中 `BYHOUR` 与 `BYMINUTE` 先生成按时间升序排列的
`11:00、11:30、14:00、14:30`，再由 `BYSETPOS=1,4` 精确保留
`11:00、14:30`。不得省略 `BYSETPOS` 而额外创建 `11:30、14:00`，
也不得误判为必须拆成两个任务。

每天执行并在本地时间 2026-12-31 23:59 后结束：

```text
DTSTART:20260917T090000
RRULE:FREQ=DAILY;UNTIL=20261231T235900
```

#### 创建与更新

- 创建前根据 `get_current_time` 返回的当前本地时间计算 DTSTART，但不要把时区写进 schedule。
- 修改 RRULE 调度规则时，同时传完整的两行 `schedule` 和 `schedule_type: "rrule"`。
- 只修改标题、query 或启用状态时，不要重写 schedule，避免改变 DTSTART 相位。
- 更新前先用 `get_cron_job` 获取已有任务，保留用户未要求修改的字段。
- 从 RRULE 中移除 `COUNT`/`UNTIL` 且用户没有要求新 deadline 时，不要在 patch 中保留旧 deadline。
- 创建或更新成功后，以返回的 `schedule`、`timezone` 和 `next_trigger_time` 为准；`next_trigger_time` 可能包含系统稳定 jitter，不要求它与原始 RRULE 命中秒级相等。

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

### 修改定时任务

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

**硬前置条件**：每次调用 `update_cron_job` 前，必须在同一任务执行中先成功调用
`get_cron_job` 获取该任务的当前完整详情，并基于返回结果构造 `patch`。即使任务 ID
或旧字段已在上下文、`list_cron_jobs`、`create_cron_job` 或此前 `update_cron_job`
结果中出现，也不得跳过 `get_cron_job` 直接更新。

**当前状态与最小 patch（硬约束）**：

- `get_cron_job` 返回的任务详情是唯一可信的当前状态基线。任务中心或其他入口的修改均为有效状态；不得用历史对话、创建时承诺、旧工具返回或模型推测覆盖该结果。
- 用户本轮明确提出的内容是唯一允许修改的增量。不得因当前状态与历史记录不一致而自行纠正、恢复或补全任何字段。
- `patch` 只能包含用户本轮明确要求改变的字段。未明确要求改变的 `title`、`schedule`、`schedule_type`、`enable`、`deadline` 一律不得传入，即使传入值与当前值相同。
- 用户说“保持不变”“原来那样”表示该字段不修改，应从 `patch` 省略；不得重新传入历史值或当前值。
- 仅追加或修改任务内容时，必须基于 `get_cron_job` 返回的 `query` 合并新增需求，且 `patch` 只能包含 `query`。严禁同时传入时间、标题、启停状态或截止时间。
- 只有用户明确要求修改时间、频率、启停、标题或截止时间时，才可传入对应字段。是否需要修改某字段存在歧义时，必须先澄清，不得根据历史承诺推断。
- 更新成功后，以 `update_cron_job` 返回的任务详情为准；不得因返回时间与历史预期不同而再次修改调度字段。

**参数填写**：

| 参数 | 规则 |
|---|---|
| `cron_job_id` | 已存在的定时任务 ID，从 `get_cron_job` 或 `list_cron_jobs` 获取 |
| `query` | 仅在用户要求修改任务内容时传。追加需求时基于 `get_cron_job` 返回的 query 合并后传入。 |
| `schedule_type` | 仅在用户明确修改时间或频率时传；与 `schedule` 同时传入，且二者必须匹配。 |
| `schedule` | 仅在用户明确修改时间或频率时传；必须匹配 `schedule_type`。 |
| `enable` | 仅在用户明确要求暂停或恢复时传入。 |
| `deadline` | 仅在用户明确要求修改截止时间时，按上方“deadline 使用规则”传入。 |

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

### 删除定时任务

使用 `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 表达式
- 「从下周开始每两周周一提醒我」→ `rrule`，完整两行 schedule，并用 DTSTART 保持双周相位
- 「每天提醒我，执行 10 次后停止」→ `rrule` + `COUNT=10`，不传 deadline
- 「每月最后一个工作日提醒我结账」→ `rrule` + `BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1`
- 「每天 11:00、14:30 提醒我」→ 一条 `rrule` + `BYSETPOS=1,4;BYHOUR=11,14;BYMINUTE=0,30`
- 「每周一检查这个 repo 并总结失败测试」→ 周期任务，写清工作区、测试命令、输出格式和失败汇报方式
- 「持续关注这个页面，价格变化时告诉我」→ 周期监控，写清 URL、登录态要求、对比标准和通知阈值
- 「把刚才的提醒改到明天 10 点」→ 多轮编辑，先指代解析定位已有任务，再输出合并需求，用户确认后 update 修改时间
- 「暂停/恢复/删除我的提醒」→ 定位已有任务后 update `enable` 或 delete

---

## 最小确认原则

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

---

## 注意事项

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