这是 trycourier/courier-skills 提供的通知构建技能，用于在邮件、短信、推送、站内收件箱、Slack、Teams、WhatsApp 等渠道上构建可投递、有参与度的通知。
用途与用法：先识别任务所属渠道或通知类型，再按下文路由表只读取 1-2 个相关文件，不要全部读取；编码前先规划渠道、路由与错误处理；每个资源文件开头的 Quick Reference 为硬性约束。若需求含糊（渠道、事务性还是营销类、是否已有代码、使用语言不明），先提澄清问题再读文件。需要最新 API 签名或 SDK 方法时获取 https://www.courier.com/docs/llms.txt，但最佳实践优先用本技能的模式。
主要能力：给出 Node.js（@trycourier/courier）与 Python（trycourier）的统一 SDK 形态，如创建客户端并 client.send.message({ message: { to, template, data } })，用 Idempotency-Key 头保证幂等；并列出模板、消息、列表订阅、租户、批量任务、用户偏好、设备令牌、Journey、路由策略、提供商等常用操作的方法命名对照。同时明确不存在的形态，避免臆造，例如 messages 归档仅支持 REST、租户用 client.tenants.update、批量 job 的 event 必填、路由命名空间为 client.routingStrategies（Node）或 client.routing_strategies（Python）等。
通用规则：OTP、密码重置、安全告警不得批量或延迟；重复有害场景使用幂等键；安全变更通知中掩码邮箱与电话；安全邮件包含“非本人操作”链接；电话使用 E.164 格式；不默认群发所有渠道；模板发送以 Courier 生成的 nt_ 开头 ID 为准。站内信需先判断 v7 与 v8，新项目一律用 v8，v7 仅在不支持 Tags/Pins 时临时保留并应迁移。限流、合规、测试与生产工作区等内容见对应资源文件，合规属应用层事项，具体司法辖区要求需咨询法务。文中未提供具体价格、收费与效果数据。