Source profileQuality 62/100

affaan-m/ECC/docs/zh-CN/skills/unified-notifications-ops/SKILL.md

unified-notifications-ops

Review unified-notifications-ops's use cases, installation, workflow, and original source instructions.

Source repository stars
234,327
Declared platforms
0
Static risk flags
0
Last source update
2026-07-27
Source checked
2026-07-28

Decision brief

What it does—and where it fits

当真正的问题不是缺少通知,而是通知系统碎片化时,使用此技能。

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/affaan-m/ECC --skill "docs/zh-CN/skills/unified-notifications-ops"
    Safe inspection promptEditorial

    Inspect the Agent Skill "unified-notifications-ops" from https://github.com/affaan-m/ECC/blob/4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38/docs/zh-CN/skills/unified-notifications-ops/SKILL.md at commit 4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      何时使用

      用户希望在 GitHub、Linear、本地钩子、桌面提醒、聊天或邮件之间建立统一的通知通道 CI 失败、审查请求、问题更新和操作员事件分散在不同的地方 当前设置制造了噪音而非行动 用户希望将重叠的通知分支或积压提案整合到一个 ECC 原生通道中 工作区已有钩子、MCP 或连接工具,但缺乏连贯的通知策略

      用户希望在 GitHub、Linear、本地钩子、桌面提醒、聊天或邮件之间建立统一的通知通道CI 失败、审查请求、问题更新和操作员事件分散在不同的地方当前设置制造了噪音而非行动
    2. 02

      首选界面

      GitHub 问题、PR、审查、评论和 CI Linear 问题/项目状态变更 本地钩子事件和会话生命周期信号 桌面通知原语 已连接的邮件/聊天界面(如果实际存在)

      GitHub 问题、PR、审查、评论和 CILinear 问题/项目状态变更本地钩子事件和会话生命周期信号
    3. 03

      不可妥协的规则

      绝不暴露令牌、密钥、Webhook 密钥或内部标识符 区分: 事件来源 严重等级 路由通道 操作员行动 当中断成本不明确时,默认采用摘要优先策略 不要将每个事件广播到所有通道 如果真正的解决方案是更好的问题分类、钩子策略或项目流程,请明确说明

      绝不暴露令牌、密钥、Webhook 密钥或内部标识符区分:事件来源

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score62/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars234,327SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guidecatalog recordEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    affaan-m/ECC
    Skill path
    docs/zh-CN/skills/unified-notifications-ops/SKILL.md
    Commit
    4e973d3eaf92d97f8d2e2d8abb39d8bdc8711b38
    License
    MIT
    Collected
    2026-07-28
    Default branch
    main
    View the original SKILL.md

    统一通知运维

    当真正的问题不是缺少通知,而是通知系统碎片化时,使用此技能。

    任务是将分散的事件整合到一个操作员界面上,包含:

    • 明确的严重等级
    • 明确的责任人
    • 明确的路由
    • 明确的后续行动

    何时使用

    • 用户希望在 GitHub、Linear、本地钩子、桌面提醒、聊天或邮件之间建立统一的通知通道
    • CI 失败、审查请求、问题更新和操作员事件分散在不同的地方
    • 当前设置制造了噪音而非行动
    • 用户希望将重叠的通知分支或积压提案整合到一个 ECC 原生通道中
    • 工作区已有钩子、MCP 或连接工具,但缺乏连贯的通知策略

    首选界面

    从已有资源出发:

    • GitHub 问题、PR、审查、评论和 CI
    • Linear 问题/项目状态变更
    • 本地钩子事件和会话生命周期信号
    • 桌面通知原语
    • 已连接的邮件/聊天界面(如果实际存在)

    优先使用 ECC 原生编排,而非建议用户采用独立的通知产品。

    不可妥协的规则

    • 绝不暴露令牌、密钥、Webhook 密钥或内部标识符
    • 区分:
      • 事件来源
      • 严重等级
      • 路由通道
      • 操作员行动
    • 当中断成本不明确时,默认采用摘要优先策略
    • 不要将每个事件广播到所有通道
    • 如果真正的解决方案是更好的问题分类、钩子策略或项目流程,请明确说明

    事件管道

    将通道视为:

    1. 捕获 事件
    2. 分类 紧急程度和责任人
    3. 路由 到正确的通道
    4. 合并 重复和低信号噪音
    5. 附加 下一个操作员行动

    目标是更少但更好的通知。

    默认严重等级模型

    等级示例默认处理方式
    严重默认分支 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 当通知痛点涉及计费/客户运营而非工程时

    Alternatives

    Compare before choosing