quick-reminders

核心用法

Quick Reminders 是一款专为短期提醒场景设计的轻量级工具，适用于48小时以内的一次性提醒需求。其核心机制采用 nohup sleep 后台进程配合 openclaw message send 命令实现，在提醒创建时由Agent合成最终消息文本，触发时刻直接发送而无需再次调用LLM，实现零token消耗。

用户通过CLI调用 nohup-reminder.sh 脚本完成操作，支持添加（add）、列出（list）、移除（remove）三种核心命令。添加提醒时需指定目标聊天ID（支持Telegram、WhatsApp、Discord、Signal、iMessage等多渠道）、触发时间（支持相对时间如30s/20m/2h/1d或ISO-8601绝对时间）以及可选时区。消息文本由Agent在创建时人工合成，强调"朋友发短信"的自然风格，避免机械化的系统通知口吻。

显著优点

极致轻量：完全规避LLM在触发时的token消耗，对于高频短期提醒场景成本优势显著。多渠道覆盖：原生支持五大主流即时通讯平台，用户可按需选择。人性化交互：内置详细的文案风格指南，鼓励使用口语化、带情感色彩的表达，提升用户体验。架构简洁：纯Shell实现，依赖仅jq和openclaw两个标准工具，部署门槛低。进程级可靠：使用nohup创建独立后台进程，配合PID管理和目录锁机制，确保提醒触发的可靠性。

潜在缺点与局限性

时间窗口受限：明确限制48小时内，超期需求需转用日历系统，增加了用户的心智负担。机器重启丢失：基于进程的实现方式导致系统重启后所有待触发提醒丢失，不适合关键任务。无持久化保障：reminders.json虽存储提醒元数据，但sleep进程状态无法恢复。单用户局限：设计为个人助手场景，不支持多用户或团队协作的提醒管理。编辑功能缺失：需先移除再重新添加，无法直接修改现有提醒。

适合的目标群体

该Skill最适合以下用户：需要频繁设置短期个人提醒的个体用户；对LLM token成本敏感、追求极致经济性的场景；偏好即时通讯渠道接收提醒而非传统通知中心；以及已深度使用OpenClaw生态、希望保持工作流一致性的用户。对于需要跨设备同步、长期规划或企业级提醒管理的场景则不太适用。

使用风险

进程管理风险：极端情况下锁目录或临时文件可能残留，虽设计有trap清理机制，但崩溃场景下仍需手动干预。时区处理复杂度：绝对时间需显式指定IANA时区， naive时间默认采用系统本地时区，跨时区使用易出错。渠道配置依赖：首次使用需从session_status或TOOLS.md获取目标ID，配置链路较长。Shell兼容性：脚本路径含反斜杠字符，在部分文件系统可能存在兼容性问题。

核心用法

quick-reminders 是一个极简的短时提醒 Skill，专为 48 小时以内的即时提醒需求设计。用户通过自然语言描述提醒内容和时间，Agent 会调用 nohup-reminder.sh 脚本创建后台进程，在指定时间通过 openclaw message send 自动推送消息。

关键特性：

• 零 LLM 消耗：提醒文本在创建时由 Agent 一次性生成，触发时不调用任何大模型
• 多通道支持：默认 Telegram，可选 WhatsApp、Discord、Signal、iMessage
• 时间灵活：支持相对时间（30s、2h、1d）和绝对 ISO-8601 时间
• 人性化文案：强调"朋友发消息"的自然语气，避免机械表达

操作示例

# 2小时后提醒
bash ./scripts/nohup-reminder.sh add "Hey, you wanted to call John" --target <chat_id> -t 2h

# 列出/删除提醒
nohup-reminder.sh list
nohup-reminder.sh remove 3

---

显著优点

| 维度 | 优势 |

|------|------|

| **成本效率** | 触发阶段零 token 消耗，对高频提醒用户极其友好 |

| **响应速度** | 本地 `nohup sleep` 实现，无需外部服务轮询 |

| **隐私控制** | 消息文本存于 `/tmp` 临时文件，权限 0600，发送后自动清理 |

| **代码质量** | 约 300 行 bash，采用 `set -euo pipefail`，无 `eval/exec` 等危险函数 |

| **依赖极简** | 仅依赖 `jq` 和 `openclaw` CLI，无 npm/pip 供应链风险 |

| **并发安全** | 实现了 mkdir-based 文件锁，防止 reminders.json 竞态写入 |

---

潜在缺点与局限性

1. 持续性限制：机器重启后提醒丢失，不适合跨会话任务
2. 48 小时天花板：设计硬性限制，超长提醒需转日历事件
3. 无重复提醒：一次性设计，不支持周期性任务
4. 无送达确认：依赖 openclaw CLI 的底层可靠性，无应用层重试
5. 调试困难：默认丢弃所有输出到 /dev/null，故障排查不便
6. 文件名瑕疵：scripts\nnohup-reminder.sh 含换行符，可能引发工具兼容问题

---

适合人群

• 高频短时提醒用户：需要一天内多次提醒，关注 API 成本
• 隐私敏感型用户：不愿将提醒内容持久化到云端日历
• 极简主义者：偏好轻量工具，不需要复杂调度功能
• 开发者/高级用户：能理解后台进程生命周期，接受手动管理

---

常规风险

| 风险项 | 级别 | 说明 |

|--------|------|------|

| 后台进程堆积 | 低 | 大量未清理提醒会创建持久进程，建议定期 `list` 检查 |

| 临时文件残留 | 低 | 异常退出可能导致 `/tmp/oclaw-rem-*.msg` 残留，可手动清理 |

| 时区混淆 | 中 | 绝对时间需显式指定 `-z` 时区，否则使用系统本地时间 |

| 目标 ID 配置 | 中 | `--target` 格式因渠道而异（Telegram chat ID vs WhatsApp E.164），需参考 TOOLS.md |

---

安全认证摘要

• 综合评分：78/100（Grade A）
• 信任等级：T2（可信组织 openclaw）
• 核心安全实践：文件锁、权限控制、输入验证、无危险函数
• 隐私合规：GDPR 数据最小化通过，敏感数据保护通过