unified-notifications-ops

name unified-notifications-ops description 将通知作为统一的 ECC 原生工作流进行操作，涵盖 GitHub、Linear、桌面提醒、钩子以及连接的通信界面。当真正的问题是告警路由、去重、升级或收件箱崩溃时使用。 origin ECC 统一通知运维 当真正的问题不是缺少通知，而是通知系统碎片化时，使用此技能。 任务是将分散的事件整合到一个操作员界面上，包含： 明确的严重等级 明确的责任人 明确的路由 明确的后续行动 何时使用 用户希望在 GitHub、Linear、本地钩子、桌面提醒、聊天或邮件之间建立统一的通知通道 CI 失败、审查请求、问题更新和操作员事件分散在不同的地方 当前设置制造了噪音而非行动 用户希望将重叠的通知分支或积压提案整合到一个 ECC 原生通道中 工作区已有钩子、MCP 或连接工具，但缺乏连贯的通知策略 首选界面 从已有资源出发： GitHub 问题、PR、审查、评论和 CI Linear 问题/项目状态变更 本地钩子事件和会话生命周期信号 桌面通知原语 已连接的邮件/聊天界面（如果实际存在） 优先使用 ECC 原生编排，而非建议用户采用独立的通知产品。 不可妥协的规则 绝不暴露令牌、密钥、Webhook 密钥或内部标识符 区分： 事件来源 严重等级 路由通道 操作员行动 当中断成本不明确时，默认采用摘要优先策略 不要将每个事件广播到所有通道 如果真正的解决方案是更好的问题分类、钩子策略或项目流程，请明确说明 事件管道 将通道视为： 捕获 事件 分类 紧急程度和责任人 路由 到正确的通道 合并 重复和低信号噪音 附加 下一个操作员行动 目标是更少但更好的通知。 默认严重等级模型 等级 示例 默认处理方式 严重 默认分支 CI 损坏、安全问题、发布受阻、部署失败 立即中断 高 请求审查、PR 失败、阻塞责任人的交接 当日提醒 中 问题状态变更、重要评论、积压变动 摘要或队列 低 重复成功、常规噪音、冗余生命周期标记 抑制或折叠 如果工作区没有严重等级模型，请先构建一个，再提出自动化方案。 工作流程 1. 盘点当前界面 列出： 事件来源 当前通道 现有的发出提醒的钩子/脚本 同一事件的重复路径 重要事项未被呈现的静默失败案例 指出 ECC 已拥有的部分。 2. 决定哪些值得中断 针对每个事件族，回答： 谁需要知道？ 他们需要多快知道？ 应该中断、批量处理还是仅记录？ 使用以下默认值： 发布、CI、安全和阻塞责任人的事件需要中断 中等信号更新使用摘要 遥测和低信号生命周期标记仅记录 3. 在添加通道前合并重复项 检查： 同一 PR 事件出现在 GitHub、Linear 和本地日志中 同一失败的重复钩子通知 应总结而非直接转发的评论或状态变更 相互重复且未提供更好行动路径的通道 优先选择： 一个规范摘要 一个责任人 一个主要通道 一个备用路径 4. 设计 ECC 原生工作流 针对每个真实通知需求，定义： 来源 门控 形态 ：即时提醒、摘要、队列或仅仪表盘 通道 行动 如果 ECC 已有原语，优先使用： 操作员分类技能 自动触发/执行的钩子 委托分类的代理 仅在真正缺少桥接时才使用 MCP/连接器 5. 返回以行动为导向的设计 最终输出： 保留什么 抑制什么 合并什么 ECC 下一步应封装什么 输出格式 当前表面 - 来源 - 渠道 - 重复项 - 缺口 事件模型 - 严重 - 高 - 中 - 低 路由计划 - 来源 -> 渠道 - 原因 - 操作员/负责人 整合 - 抑制 - 合并 - 规范摘要 下一步ECC行动 - 技能/钩子/代理/MCP - 下一步要构建的具体工作流 推荐规则 优先选择一条强通道而非多条弱通道 中等和低信号更新优先使用摘要 信号应自动触发时优先使用钩子 工作涉及分类、路由和审查优先决策时优先使用操作员技能 当根本原因是积压/PR 协调而非提醒时，优先使用 project-flow-ops 当用户首先需要来源盘点时，优先使用 workspace-surface-audit 如果桌面通知已足够，不要发明不必要的外部桥接 良好用例 "我们有 GitHub、Linear 和本地钩子提醒，但没有统一的操作员流程" "我们的 CI 失败噪音很大，人们都忽略了" "我想要一个跨 Claude、OpenCode 和 Codex 界面的统一通知策略" "判断哪些应该中断，哪些应该进入摘要" "将重叠的通知 PR 想法合并为一个规范的 ECC 通道" 相关技能 workspace-surface-audit project-flow-ops github-ops knowledge-ops customer-billing-ops 当通知痛点涉及计费/客户运营而非工程时