Scheduler Notification Runbook
Overview
Use this skill to create reliable reminder and scheduled notification workflows with OpenClaw cron.
Focus on production-safe decisions: choose the correct payload type, choose the correct session target, write reminder text that still makes sense when delivered later, and verify that the job actually fired and delivered.
Core workflow
1. Classify the scheduling need
Decide which of these cases applies before creating any job:
- - One-shot reminder: "Remind me in 20 minutes" or "Remind me tomorrow at 9 AM"
- Recurring reminder: "Remind me every weekday at 6 PM"
- Background agent task: a scheduled isolated agent run that produces a summary or follow-up
- Current-session follow-up: a scheduled agent run that must keep using the current session thread
If the request is only a reminder and does not need reasoning at fire time, prefer a systemEvent reminder.
If the request needs the agent to think, check state, summarize, or perform a task when the time arrives, prefer an agentTurn job.
2. Choose the payload type
Use this decision rule:
Use payload.kind = "systemEvent" when:
- - The future action is a plain reminder
- The message can be fully written now
- No tool use or reasoning is needed when it fires
- The user mainly wants a notification, not a follow-up workflow
This is the default reminder pattern for simple reminders.
Use payload.kind = "agentTurn" when:
- - The scheduled task must inspect context or perform work later
- The task needs tool use, web access, summarization, or decision-making at fire time
- The task should produce a delivery summary after it completes
- The task must be bound to the current session or a named persistent session
Do not use agentTurn just to send a basic reminder that could be expressed in plain text.
3. Choose the session target
Match sessionTarget to the payload and the desired behavior.
Use sessionTarget = "main"
Only with payload.kind = "systemEvent".
Use this for normal reminder injection into the main session.
Recommended when:
- - The user asked for a straightforward reminder
- The reminder should appear like a natural follow-up in the main conversation
Use sessionTarget = "isolated"
Only with payload.kind = "agentTurn".
Use this for scheduled work that should run independently and optionally announce a summary.
Recommended when:
- - The task should not rely on the current thread
- The task may be long-running or more operational
- You want isolated execution with clear delivery behavior
Use sessionTarget = "current"
Only with payload.kind = "agentTurn".
Use this when the future agent run must stay attached to the current session context.
Recommended when:
- - The user explicitly wants the follow-up in the same thread
- The current session context matters later
Use sessionTarget = "session:<name>"
Only with payload.kind = "agentTurn".
Use this for durable named workflows that should accumulate their own thread history.
Recommended when:
- - You are building a recurring operational workflow
- The job should write into a stable named session rather than a transient isolated run
Writing reminder text
Reminder text quality matters because the user will read it later, not now.
Write the text as if it has already arrived in the future.
Rules for good reminder text
- - Explicitly say it is a reminder when the time gap is meaningful
- Include the original task or intent
- Include enough context so the user does not have to remember why it was scheduled
- Keep it short and readable
- Avoid raw implementation details such as cron expressions, session targets, job IDs, or internal payload terms
Good patterns
Short-delay reminder
Use for reminders in minutes or within the same day:
- - INLINECODE14
- INLINECODE15
- INLINECODE16
Next-day or dated reminder
Use for tomorrow or specific dates/times:
- - INLINECODE17
- INLINECODE18
- INLINECODE19
Context-rich reminder
Use when the reminder could be ambiguous later:
- - INLINECODE20
- INLINECODE21
- INLINECODE22
Avoid
- - INLINECODE23
- INLINECODE24
- INLINECODE25
- INLINECODE26
- Any text that only makes sense to an implementer
Schedule selection
Pick the simplest schedule that matches the request.
Use schedule.kind = "at" when:
- - The reminder should happen once at a specific time
- The request is phrased as "in 20 minutes" or "tomorrow at 9"
Use schedule.kind = "every" when:
- - The reminder repeats on a fixed interval
- Exact calendar semantics are not required
Use schedule.kind = "cron" when:
- - The reminder repeats on calendar-based rules
- The user asks for things like every weekday, every Monday, or the first day of each month
Prefer the least complex schedule that accurately matches the request.
Delivery decisions for agent jobs
Delivery matters only for agentTurn jobs.
Use delivery.mode = "announce" when:
- - The result should be posted back into chat after the isolated run finishes
- The user expects a visible summary
Use delivery.mode = "none" when:
- - The task is internal and does not need to notify chat directly
- Another system consumes the result
Use delivery.mode = "webhook" when:
- - The scheduled run must call an external HTTP endpoint
- The user explicitly wants webhook delivery
Do not try to simulate webhook behavior through ad hoc messaging if webhook delivery is the correct abstraction.
Validation workflow
Always validate after creating or updating a scheduled reminder workflow.
Minimum validation checklist
- 1. Confirm the schedule shape matches the request
- Confirm the payload type matches the real need
- Confirm the session target is valid for that payload
- Confirm the reminder text reads naturally in the future
- Confirm the job is enabled
- Capture the returned INLINECODE34
Recommended follow-up checks
- - Run the job manually when safe and useful
- Inspect run history for recurring jobs
- Confirm that delivery occurred in the expected place
- If the reminder is time-sensitive, verify timezone assumptions explicitly
Troubleshooting
Use this sequence when a scheduled reminder or notification did not behave as expected.
Problem: the job was created but nothing happened
Check:
- - Whether the job is enabled
- Whether the schedule is in the future or already missed
- Whether the timezone assumption was wrong
- Whether the scheduler is healthy
- Whether the wrong session target was used
Problem: the job fired but the message was confusing
Check:
- - Whether the reminder text included enough future context
- Whether the text referred to internal details instead of user intent
- Whether the reminder should have been written as a richer natural reminder
Problem: an agentTurn job ran but did not deliver visibly
Check:
- - Whether
delivery.mode was omitted or set incorrectly - Whether the task was isolated with announce delivery as intended
- Whether the target channel or recipient was specified when needed
Problem: the wrong session received the follow-up
Check:
- - Whether
main, isolated, current, or session:<name> was selected correctly - Whether the user wanted a reminder injection or a future agent run
- Whether a named session would be more stable than INLINECODE41
Problem: the reminder should have been simple but was over-engineered
Check:
- - Whether
agentTurn was used when systemEvent was enough - Whether unnecessary delivery settings were added
- Whether a one-shot
at reminder would have solved the request more directly
Production guidance for ClawHub publication
When packaging this as a reusable public skill, keep the skill focused on durable decision-making rather than local environment specifics.
Include
- - Clear payload selection rules
- Session target selection guidance
- Reminder text quality rules
- Validation and troubleshooting steps
- Examples framed around real reminder requests
Exclude
- - Local machine assumptions
- Environment-specific secrets or tokens
- Internal-only customer identifiers
- Hard-coded job IDs or one-off operational artifacts
Reference material
Read references/cron-patterns.md when you need compact pattern guidance for one-shot reminders, recurring reminders, and agent-run notification workflows.
Read references/examples.md when you need ClawHub-friendly examples that show the difference between simple reminders, recurring reminders, isolated agent jobs, and same-thread follow-ups.
调度器通知运行手册
概述
使用此技能通过OpenClaw cron创建可靠的提醒和定时通知工作流。
专注于生产环境安全的决策:选择正确的负载类型,选择正确的会话目标,编写在稍后送达时仍有意义的提醒文本,并验证任务是否实际触发并送达。
核心工作流
1. 分类调度需求
在创建任何任务之前,确定适用于以下哪种情况:
- - 一次性提醒:20分钟后提醒我或明天上午9点提醒我
- 重复提醒:每个工作日晚上6点提醒我
- 后台代理任务:产生摘要或后续操作的定时独立代理运行
- 当前会话后续操作:必须继续使用当前会话线程的定时代理运行
如果请求仅为提醒且不需要在触发时进行推理,优先使用systemEvent提醒。
如果请求需要代理在时间到达时进行思考、检查状态、总结或执行任务,优先使用agentTurn任务。
2. 选择负载类型
使用以下决策规则:
使用payload.kind = systemEvent当:
- - 未来操作是纯文本提醒
- 消息现在即可完整编写
- 触发时无需使用工具或进行推理
- 用户主要需要通知,而非后续工作流
这是简单提醒的默认提醒模式。
使用payload.kind = agentTurn当:
- - 定时任务必须稍后检查上下文或执行工作
- 任务在触发时需要工具使用、网络访问、总结或决策
- 任务完成后应生成交付摘要
- 任务必须绑定到当前会话或指定的持久会话
不要仅为了发送可以用纯文本表达的基本提醒而使用agentTurn。
3. 选择会话目标
根据负载和期望行为匹配sessionTarget。
使用sessionTarget = main
仅与payload.kind = systemEvent配合使用。
用于将普通提醒注入主会话。
推荐场景:
- - 用户请求了直接的提醒
- 提醒应像自然后续操作一样出现在主对话中
使用sessionTarget = isolated
仅与payload.kind = agentTurn配合使用。
用于应独立运行并可选择宣布摘要的定时工作。
推荐场景:
- - 任务不应依赖当前线程
- 任务可能是长时间运行或更具操作性
- 需要具有清晰交付行为的独立执行
使用sessionTarget = current
仅与payload.kind = agentTurn配合使用。
当未来的代理运行必须保持与当前会话上下文关联时使用。
推荐场景:
- - 用户明确希望后续操作在同一线程中
- 当前会话上下文稍后仍然重要
使用sessionTarget = session:
仅与payload.kind = agentTurn配合使用。
用于应积累自身线程历史的持久命名工作流。
推荐场景:
- - 正在构建重复性操作工作流
- 任务应写入稳定的命名会话,而非临时独立运行
编写提醒文本
提醒文本质量很重要,因为用户将在稍后阅读,而非现在。
编写文本时,应如同它已经到达未来。
优秀提醒文本的规则
- - 当时间间隔有意义时,明确说明这是提醒
- 包含原始任务或意图
- 包含足够的上下文,使用户无需记住为何安排
- 保持简短易读
- 避免原始实现细节,如cron表达式、会话目标、任务ID或内部负载术语
良好模式
短延迟提醒
用于几分钟内或同一天的提醒:
- - 提醒:20分钟后检查构建。
- 提醒:现在加入设计评审。
- 提醒:今天下午给Alex发送后续消息。
次日或指定日期提醒
用于明天或特定日期/时间:
- - 提醒:今天上午审阅OrAHub CLI快速入门草稿。
- 提醒:下午3点与合作伙伴团队的会议即将开始。
- 提醒:今天提交调度器技能的法律审阅笔记。
上下文丰富的提醒
当提醒稍后可能产生歧义时使用:
- - 提醒:跟进调度器通知运行手册技能以发布到ClawHub。
- 提醒:检查重复提醒演示是否实际送达主会话。
- 提醒:重新审视OrAHub凭证接入流程,决定npm还是curl应为默认安装路径。
避免
- - ping
- 做那件事
- 定时任务已触发
- cron成功触发
- 任何只有实施者才能理解的文本
调度选择
选择与请求匹配的最简单调度。
使用schedule.kind = at当:
- - 提醒应在特定时间发生一次
- 请求表述为20分钟后或明天9点
使用schedule.kind = every当:
使用schedule.kind = cron当:
- - 提醒基于日历规则重复
- 用户要求诸如每个工作日、每个周一或每月第一天之类的内容
优先选择准确匹配请求的最简单调度。
代理任务的交付决策
交付仅对agentTurn任务有意义。
使用delivery.mode = announce当:
- - 独立运行完成后,结果应回发到聊天中
- 用户期望可见的摘要
使用delivery.mode = none当:
- - 任务是内部的,不需要直接通知聊天
- 其他系统消费结果
使用delivery.mode = webhook当:
- - 定时运行必须调用外部HTTP端点
- 用户明确希望webhook交付
如果webhook交付是正确的抽象,不要试图通过临时消息模拟webhook行为。
验证工作流
创建或更新定时提醒工作流后,务必进行验证。
最低验证清单
- 1. 确认调度形状与请求匹配
- 确认负载类型符合实际需求
- 确认会话目标对该负载有效
- 确认提醒文本在未来读起来自然
- 确认任务已启用
- 记录返回的jobId
推荐的后续检查
- - 在安全且有用时手动运行任务
- 检查重复任务的运行历史
- 确认交付发生在预期位置
- 如果提醒对时间敏感,明确验证时区假设
故障排除
当定时提醒或通知未按预期运行时,使用此顺序排查。
问题:任务已创建但未发生任何事
检查:
- - 任务是否已启用
- 调度是否在未来或已错过
- 时区假设是否错误
- 调度器是否健康
- 是否使用了错误的会话目标
问题:任务已触发但消息令人困惑
检查:
- - 提醒文本是否包含足够的未来上下文
- 文本是否引用内部细节而非用户意图
- 提醒是否应编写为更丰富的自然提醒
问题:agentTurn任务已运行但未可见交付
检查:
- - delivery.mode是否被省略或设置错误
- 任务是否按预期以宣布交付方式独立运行
- 需要时是否指定了目标频道或接收者
问题:错误的会话接收了后续操作
检查:
- - main、isolated、current或session:是否正确选择
- 用户想要的是提醒注入还是未来的代理运行
- 命名会话是否比current更稳定
问题:提醒本应简单但过度设计
检查:
- - 是否在systemEvent足够时使用了agentTurn
- 是否添加了不必要的交付设置
- 一次性at提醒是否更直接地解决了请求
ClawHub发布的生产指导
当将此打包为可重用的公共技能时,保持技能专注于持久决策而非本地环境细节。
包含
- - 清晰的负载选择规则
- 会话目标选择指导
- 提醒文本质量规则
- 验证和故障排除步骤
- 围绕真实提醒请求构建的示例
排除
- - 本地机器假设
- 环境特定的密钥或令牌
- 仅限内部的客户标识符
- 硬编码的任务ID或一次性操作工件
参考资料
当需要一次性提醒、重复提醒和代理运行通知工作流的紧凑模式指导时,阅读references/cron-patterns.md。
当需要展示简单提醒、重复提醒、独立代理任务和同线程后续操作之间差异的ClawHub友好示例时,阅读references/examples.md。