Notify

核心用法

Notify 技能是一个集中式的通知管理枢纽，设计用于解决 AI 助手与用户之间的信息触达问题。其核心理念是"用户决定何时、何地、收到什么"。

三大功能模块：

1. 通道偏好配置 - 支持按优先级路由（urgent/normal/digest）选择不同渠道（Pushover、ntfy、Email、当前对话等），并可设置免打扰时段
2. 条件触发器（Watchers） - 用户通过自然语言设置"当 X 发生时通知我"，系统自动创建监控规则并跟踪状态
3. 通知日志 - 完整记录每条通知的发送时间、渠道、内容与触发来源，支持溯源查询

典型工作流：

用户: "Notify me when deploy completes"
→ 创建 Watcher [w1] deploy completes | push | active
→ 条件满足时 → 按优先级路由至 push 渠道
→ 记录日志 [timestamp] push | "Deploy complete" | w1

显著优点

• 去中心化设计：不依赖单一推送服务，支持多提供商冗余
• 用户主权明确：DND 时段、优先级规则完全由用户配置，避免侵扰
• 可追溯性强：每条通知都有 trigger 标记，可回答"为什么收到这条消息"
• 条件即代码：自然语言直接转化为可执行的监控规则

潜在局限

• 外部依赖风险：Push 提供商（Pushover/ntfy）的可用性直接影响紧急通知
• 条件表达力边界：复杂条件（如"当 A 且 B 但非 C"）可能需要更精确的定义
• 无内置持久化：依赖 markdown 文件存储，高并发场景可能有限制
• 跨设备同步：未明确说明多设备间的 watcher 状态同步机制

适合人群

• 需要监控异步任务完成状态的开发者/运维人员
• 希望过滤信息噪音、只接收关键事件通知的知识工作者
• 使用多平台工具链、需要统一通知出口的高级用户

常规风险

• 通知疲劳：Watcher 规则设置过于宽泛可能导致消息轰炸
• 渠道单点故障：过度依赖单一 push 提供商可能遗漏关键警报
• 隐私泄露：Push 通知内容可能经过第三方服务，敏感信息需谨慎
• 时区/作息误判：DND 配置不当可能导致紧急通知被错误压制

核心用法

Notify 是一个纯文档型 Skill，用于帮助用户系统化地管理通知偏好、条件告警和通知历史。它不执行任何代码，仅提供结构化的 Markdown 模板，让用户通过编辑文档来配置：

1. 通知渠道偏好 — 按优先级（urgent/normal/digest）指定不同发送渠道
2. 勿扰时段 — 设置非紧急通知的静默规则
3. 推送服务商 — 记录 Pushover、ntfy 等外部服务的配置信息
4. 条件告警（Watchers） — 建立 "当 X 发生时通知我" 的监听规则
5. 通知日志 — 手动追踪已发送的通知记录

用户通过自然语言指令与系统交互，如 "Notify me when deploy completes" 会自动添加 Watcher 条目。

显著优点

• 绝对安全：T-MD 纯文档分类，无可执行代码、零依赖、无网络调用
• 高度透明：所有配置和记录均以纯文本形式呈现，用户完全可控
• 灵活扩展：支持任意通知服务商，文档结构易于自定义
• 审计友好：完整的通知历史日志，便于回溯和排查

潜在局限

• 无自动化执行：需配合其他系统或人工操作才能实现真正的通知推送
• 依赖外部工具：Pushover、ntfy 等服务的实际调用需另行配置
• 无内置验证：文档中的配置格式错误不会被自动检测
• 手动维护成本：Watchers 状态、日志记录均需人工更新

适合人群

• 希望以文本方式集中管理通知配置的技术用户
• 需要将通知策略与执行系统解耦的架构设计者
• 对安全性有极高要求、拒绝任何代码执行的场景
• 已拥有独立通知基础设施（如 ntfy 自托管服务器）的用户

常规风险

• 配置遗漏：因纯手动维护，可能出现 Watchers 与实际执行逻辑不同步
• 敏感信息暴露：虽无硬编码密钥，但用户可能在文档中明文记录 API token
• 误删风险：Markdown 格式无强制约束，误删关键行可能导致配置丢失
• 语义歧义：自然语言条件（如 "email from boss"）缺乏严格定义，理解可能偏差