auto: sync OpenClaw config 2026-09-18 10:13

agents/main/agent/workshop-skills/scheduled-reminders/SKILL.md

@@ -84,25 +84,37 @@ openclaw cron add "打卡检查" \
   --message '检查打卡：用 sessions_history 读会话 agent:main:dingtalk-connector:direct:0464031658857345 今天的消息；若用户在提醒时间后回复过「打卡」则回 NO_REPLY，否则发一条温和催促。'
 ```
 
-## 盘点已有提醒（用户问「某提醒还在不在 / 是不是在钉钉」时）
+## 盘点已有提醒（用户问「某提醒还在不在 / 是不是在钉钉 / 提醒看到了吗」时）
 
 1. `automations list`（`includeDisabled: true`）按 `name` 定位目标；返回已含 `schedule`、`effectiveAgentId`、`nextRunAt`。
 2. 对关心的每条 `automations get <jobId>`，确认 `agentId=main`、`delivery.mode=announce`，并读实际 `delivery.channel`/`to` 回报它是投到钉钉还是飞书（不要默认钉钉）。
-3. 回报时给下次触发时间 + 上次投递结果（`state.lastDeliveryStatus=delivered` 才算真的发出去过）。
+3. 用户问「发出去没有 / 我收到了吗」时查历史：`openclaw cron runs <jobId>`，读最近几条的 `status`、`completionStatus`、`delivered`、`summary`。
+4. **区分「设计内静默」与「投递失败」**：`delivered=false` 且 `deliverySuppressionReason` 为 `empty`（payload 没输出任何内容）或 `silent`（agent 回 `NO_REPLY`）属正常静默，不是故障。本机「视频监督踢水」带周末/节假日不出声逻辑，非工作日的 `empty` 即此类；护肤打卡检查的 `silent` 即用户已打卡。只有报错（`lastDeliveryError` 非空、`denied`、`Feishu send failed`）才算真失败，不要见 `not-delivered` 就报警。
+5. 回报时给下次触发时间 + 上次结果，并写明是「已送达」还是「设计内静默」。
+6. **清残留**：默认列表不显示已禁用任务，用 `openclaw cron list --all` 才会列出。确认无用后 `openclaw cron rm <id>`；若报 `Automation not found`，说明该条已删成功（列表快照可能滞后），重新 `list --all` 复核即可，不要重复删或改其它任务。
 
 ## 修改 / 删除
 
-- 改文案/时间：`openclaw cron edit <id> --command '...'`（或 `--cron`/`--message`），也可用 `automations` 工具的 `update <jobId>`
+- 改时间/周期：`openclaw cron edit <id> --cron ...`，或 `automations` 工具的 `update <jobId>`。
+- **command 型 payload 只能用 CLI 改**：`automations` 工具的 `update` 不接受 `payload.kind="command"`，会报 `job.payload.kind: must be equal to one of the allowed values`（实测）；agentTurn 型（`--message`）才用 `automations update`。
+- **改已有 command payload 时不要手抄原脚本**（脚本常含换行与引号，手抄必错）：先 `openclaw cron get <id>` 取 `payload.argv`，在 Python 里改，再用完整 argv 的 JSON 写回：
+  ```bash
+  openclaw cron edit <id> --command-argv '["sh","-lc","..."]'
+  ```
+  脚本嵌在 `sh -lc "..."` 双引号内、内部引号是转义形式 `\"`，用带普通引号的锚点做字符串匹配会 **0 命中**（实测）；改按**行定位**：找到含唯一文本的那行，沿用它的缩进与转义风格，在其后插入新行。
+- **改完先本地验证再交给调度器**：把回读的 `payload.argv` 直接 `subprocess.run(argv)` 跑一遍，确认 stdout 就是预期文案。仅对 `echo`/`print` 这类无副作用的文案 payload 这样做；有副作用的 payload 不要本地执行。
 - 删除：`openclaw cron rm <id>`
 
 ## 临时改一次（某晚停用某产品、出门在外等）
 
 只改周期任务的 payload 就完事，会一直错下去；要配一条恢复任务：
 
-1. 用 `automations update <jobId>`（或 `openclaw cron edit <id> --command '...'`）把周期任务换成当晚版本。
-2. 回读 `automations get <jobId>` 确认文案已生效，再继续。
+1. 用 `openclaw cron edit <id> --command '...'`（command 型 payload 不能用 `automations update`，见「修改 / 删除」）把周期任务换成当晚版本。
+2. 回读 `openclaw cron get <id>` 确认文案已生效，再继续。
 3. 同期建一条一次性任务，在次日合适时间把 payload 改回标准版本。它跑在 isolated 会话、**没有本次对话的记忆**，所以 message 必须写全 jobId 与目标文案原文，并注明改完回读校验、成功即回 `NO_REPLY`。
 4. 恢复任务不需要给人看：按核心规则加 `--no-deliver`。
+5. **次日要回读确认恢复已执行**：该任务跑完自删，不会留在列表里，所以要 `openclaw cron get <目标 jobId>` 检查周期任务文案是否已还原，再回 `cron runs` 看恢复任务是否 `ok`。
+6. 一次临时改动可能同时影响多条同类任务（如修复期同时改周四、周五两条），逐条核对文案是否互相打架，别只改一条。
 
 ## 参考