Courier 通知构建技能
让 AI 编码助手用 Courier 正确集成邮件、短信、推送、应用内收件箱、Slack、Teams 和 WhatsApp 通知，并定位投递失败原因。
证据显示该技能以文档为主，不含可执行脚本；明确要求将抓取的外部文档内容视为数据而非指令（防提示注入），推荐幂等键、E.164、不滥发渠道等安全习惯，API密钥走环境变量。扣分项：无用户确认/最小权限机制（发送真实消息、写用户资料等外部效果仅靠惯例约束），发布者身份未经注册库验证，归属与回滚路径依赖仓库上下文而非技能本身。
文档自洽性高：SKILL.md 明确优先级（canonical shape 优先于分文件）、500 上限、状态机语义、排查阶梯，引用文件间交叉链接一致。但静态审查封顶10分：提供的文件中无测试套件或执行证据，关键路径（如 inbox 的 routing: null 诊断、token 状态清理）仅有声明式描述，未可复现。
场景与受众清晰（用 Courier 构建通知的开发者），有明确的 'Not covered here' 非适用边界和触发描述。扣分项：核心功能完全依赖 Courier API 与 docs MCP 等海外服务，未评估中国大陆可达性；无中文支持说明；部分触发条件依赖用户已安装 SDK。
信息架构分层优秀（入口 SKILL.md + 按需引用表 + Quick Reference），MIT 许可、命名稳定、已知局限（如 EU data residency、auditEvents 无文档）有披露。扣分项：技能本身无版本号或 changelog，更新与维护责任仅隐含在仓库层面，部分假设（如 MCP 端点可用）未提供故障后备。
输出为可直接使用的代码模板和排查流程，边际价值高于手动查文档（内置最佳实践、状态语义表、provider 覆盖差异说明）。静态审查封顶7分：无代表性输出的执行验证，正确性依赖文档声明，实际可用性未经证实。
内部多文件交叉印证一致，区分事实与推断（如明确标注 provider error 为字符串不可模式匹配），并给出验证方法论（SDK 类型为 ground truth、.md 文档页、404 会显式失败）。但封顶5分：所有关键主张均为作者声明，无第三方执行证据或独立复现材料。
- 静态审查，未执行任何代码或 API 调用；所有正确性主张均来自文件本身。
- 技能核心依赖 Courier API、docs MCP 与 cli 等海外服务，中国大陆网络可达性未验证，使用前请自行确认。
- 发布者未经 FollowSkills 注册库验证，身份按未知处理。
- 无技能级版本号/changelog，API 形态可能随上游 SDK 变化，使用时应按技能指引对照已安装 SDK 类型核验。
- 无中文内容支持。
这个 Skill 能做什么，适合哪些场景？
这是 Courier 官方发布的 Agent Skill，将一套经过验证的通知领域知识打包给 AI 编码助手。它覆盖从发送、模板、Elemental 内容格式、多渠道路由、用户偏好，到旅程（journeys）与投递调试的完整链路。技能核心是一份 SKILL.md 入口，通过 Where to Look 表格按任务路由到具体参考文件。所有 API 调用形态均以项目实际安装的 SDK 类型定义为准绳，并明确指示助手不要凭记忆编造签名。适合任何支持 Agent Skills 标准的助手（Claude Code、Cursor、Codex 等）。
技能以纯知识库方式工作：SKILL.md 根据任务指路到对应的 references 文件（渠道指南、transactional/lifecycle 模式、journeys、reliability 等）；提供 Node 和 Python SDK 的标准调用形态（client.send.message 及 22 个命名空间的完整清单）；规定通用规则（幂等键、E.164 电话格式、模板 nt_ ID 为准）；给出投递失败排查阶梯（courier messages list → history → content）和消息状态表（DELIVERED、UNDELIVERABLE 等）；并说明如何用安装的 SDK 类型、docs MCP（docs.courier.com/docs/mcp）和 CLI 验证 API 形态。它自身不执行代码，而是约束助手写出可运行的 Courier 代码。
- 后端开发者要在 Node 或 Python 服务里发出欢迎邮件、订单回执或 OTP，需要一次写对 client.send.message 的调用形态
- 前端团队要在 React 或 React Native 应用里加应用内通知中心（Courier Inbox，JWT 鉴权、实时更新）
- 工程师要做多步流程，如每日摘要聚合、推送失败后回退到邮件、A/B 测试，需要用 journeys 的 JSON 图来编排
- 团队要统一管理多渠道通知，让用户自选订阅偏好（preference topics、托管偏好页）
- B2B SaaS 需要按租户（tenant）区分品牌、偏好默认值和模板
- 运维排查某条消息为何未送达，需要 CLI 事件时间线和渠道层细节（SPF/DKIM、10DLC 等）
这个 Skill 有哪些优点和局限？
- 官方维护，API 形态要求对照已安装 SDK 的类型定义验证，降低代码跑不通的风险
- 覆盖面完整：七个渠道、事务型与营销型通知、journeys、偏好、租户、批量发送（Bulk API）
- 有明确的失败排查方法论（requestId → messages list → history → content）和状态语义表
- 知识组织合理，按任务路由文件而非要求通读全部参考
- 深度绑定 Courier 平台，不用 Courier 的团队没有价值
- 源材料未见自动化测试套件或对 SKILL.md 路由效果的验证证据
- 广播（broadcasts）、Test→Production 环境提升、EU 数据驻留、审计事件无专门文档，需借助 docs MCP 补查
- 完整发挥需要网络访问和（部分场景）MCP 或 CLI，纯离线环境下验证能力受限
- 文档未声明对其他通知平台（如 OneSK、Knock）的对比或迁移指引
如何安装这个 Skill？
三种方式（README 均给出命令）：1) 通用安装：npx skills add trycourier/courier-skills；2) Claude Code 插件：/plugin marketplace add trycourier/courier-skills，然后 /plugin install courier@courier-skills（自带文档 MCP，用 /plugin update courier@courier-skills 更新）；3) 手动克隆：git clone https://github.com/trycourier/courier-skills.git，把 skills/courier 目录复制到 ~/.cursor/skills/ 或 ~/.claude/skills/。发现机制靠 SKILL.md 的 name/description frontmatter，无需额外配置。
如何使用这个 Skill？
安装后直接用自然语言向助手提需求，例如『从我的 Node 后端发一封欢迎邮件』或『为什么这条消息没送达？』。技能会自动路由到对应参考文件并给出代码。要求：项目需能访问网络调用 Courier API，API 密钥从环境变量 COURIER_API_KEY 读取；调试投递问题时需要安装 Courier CLI；若项目已装 @trycourier/courier 或 trycourier，技能会跳过安装步骤直接使用现有 client。源文档未说明在无 MCP/CLI 环境下哪些功能会降级。
这个 Skill 与同类方案有什么区别？
源材料未点名竞品。它本身是 Courier 平台专属技能；README 提到可集成大量第三方投递服务商（SendGrid、Amazon SES、Twilio、FCM 等），但这属于 Courier 的 provider 生态，而非同类技能的替代方案。