unified-notifications-ops

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Unified Notifications Ops

统一通知运维

Use this skill when the real problem is not a missing ping. The real problem is a fragmented notification system.

The job is to turn scattered events into one operator surface with:

clear severity
clear ownership
clear routing
clear follow-up action

当核心问题不是缺少消息提醒，而是通知系统碎片化时，请使用这个skill。

我们的目标是将分散的事件整合到单一运营界面，具备以下特性：

清晰的严重等级
明确的权责归属
清晰的路由规则
明确的后续处理动作

When to Use

适用场景

the user wants a unified notification lane across GitHub, Linear, local hooks, desktop alerts, chat, or email
CI failures, review requests, issue updates, and operator events are arriving in disconnected places
the current setup creates noise instead of action
the user wants to consolidate overlapping notification branches or backlog proposals into one ECC-native lane
the workspace already has hooks, MCPs, or connected tools, but no coherent notification policy

用户希望打通GitHub、Linear、本地hooks、桌面提醒、聊天工具、邮件的统一通知通道
CI失败、评审请求、issue更新、运营事件分散在不同渠道
现有配置产生大量噪音而非有效行动指引
用户希望将重叠的通知分支或待办提案整合到单一ECC原生通道
工作区已经配置了hooks、MCP或已连接相关工具，但缺乏统一的通知策略

Preferred Surface

优先使用的渠道

Start from what already exists:

GitHub issues, PRs, reviews, comments, and CI
Linear issue/project movement
local hook events and session lifecycle signals
desktop notification primitives
connected email/chat surfaces when they actually exist

Prefer ECC-native orchestration over telling the user to adopt a separate notification product.

从现有资源出发：

GitHub issues、PR、评审、评论、CI
Linear issue/项目状态变动
本地hook事件和会话生命周期信号
桌面通知基础能力
已实际接入的邮件/聊天渠道

优先使用ECC原生编排能力，而不是建议用户额外采购独立的通知产品。

Non-Negotiable Rules

不可违反的规则

never expose tokens, secrets, webhook secrets, or internal identifiers
separate:
- event source
- severity
- routing channel
- operator action
default to digest-first when interruption cost is unclear
do not fan out every event to every channel
if the real fix is better issue triage, hook policy, or project flow, say so explicitly

绝不泄露tokens、密钥、webhook密钥或内部标识符
明确区分以下要素：
- 事件来源
- 严重等级
- 路由渠道
- 运营处理动作
当中断成本不明确时，默认优先采用摘要推送模式
不要将所有事件全量推送到所有渠道
如果根因是issue分级、hook策略或项目流程优化问题，请明确告知

Event Pipeline

事件处理管线

Treat the lane as:

Capture the event
Classify urgency and owner
Route to the correct channel
Collapse duplicates and low-signal churn
Attach the next operator action

The goal is fewer, better notifications.

将通知通道按以下流程处理：

捕获事件
分级紧急程度和负责人
路由到正确的渠道
折叠重复事件和低价值变动
附带下一步运营处理动作

目标是推送数量更少、质量更高的通知。

Default Severity Model

默认严重等级模型

Class	Examples	Default handling
Critical	broken default-branch CI, security issue, blocked release, failed deploy	interrupt now
High	review requested, failing PR, owner-blocking handoff	same-day alert
Medium	issue state changes, notable comments, backlog movement	digest or queue
Low	repeat successes, routine churn, redundant lifecycle markers	suppress or fold

If the workspace has no severity model, build one before proposing automation.

等级	示例	默认处理方式
严重	默认分支CI故障、安全问题、版本发布阻塞、部署失败	立即触发提醒
高优	请求评审、PR执行失败、责任人阻塞的交接事项	当日内推送提醒
中优	issue状态变更、重要评论、待办事项变动	摘要推送或存入队列
低优	重复成功通知、常规变动、冗余生命周期标记	静默或合并推送

如果工作区没有现有严重等级模型，在提出自动化方案前需要先搭建等级模型。

Workflow

工作流

1. Inventory the current surface

1. 盘点现有渠道

List:

event sources
current channels
existing hooks/scripts that emit alerts
duplicate paths for the same event
silent failure cases where important things are not being surfaced

Call out what ECC already owns.

列出以下内容：

事件来源
当前推送渠道
现存的发送告警的hooks/脚本
同一事件的重复推送路径
重要事件未透出的静默失败场景

明确标注ECC已经覆盖的范围。

2. Decide what deserves interruption

2. 确定需要触发中断的场景

For each event family, answer:

who needs to know?
how fast do they need to know?
should this interrupt, batch, or just log?

Use these defaults:

interrupt for release, CI, security, and owner-blocking events
digest for medium-signal updates
log-only for telemetry and low-signal lifecycle markers

针对每一类事件，明确以下问题：

谁需要知晓？
需要在多长时间内知晓？
应该触发中断、批量推送还是仅记录日志？

使用以下默认规则：

版本发布、CI、安全、责任人阻塞类事件触发中断
中等价值更新采用摘要推送
埋点数据和低价值生命周期标记仅记录日志

3. Collapse duplicates before adding channels

3. 新增渠道前先折叠重复通知

Look for:

the same PR event appearing in GitHub, Linear, and local logs
repeated hook notifications for the same failure
comments or status churn that should be summarized instead of forwarded raw
channels that duplicate each other without adding a better action path

Prefer:

one canonical summary
one owner
one primary channel
one fallback path

排查以下场景：

同一PR事件同时出现在GitHub、Linear和本地日志中
同一故障触发重复hook通知
应汇总而非直接转发的评论或状态变动
没有提供更优行动路径的重复渠道

优先采用：

单一权威汇总信息
单一责任人
单一主渠道
单一兜底路径

4. Design the ECC-native workflow

4. 设计ECC原生工作流

For each real notification need, define:

source
gate
shape: immediate alert, digest, queue, or dashboard-only
channel
action

If ECC already has the primitive, prefer:

a skill for operator triage
a hook for automatic emission/enforcement
an agent for delegated classification
an MCP/connector only when a real bridge is missing

针对每个实际通知需求，定义：

来源
闸门规则
形式：立即提醒、摘要、队列、仅展示在看板
渠道
处理动作

如果ECC已经具备对应基础能力，优先使用：

用于运营分级的skill
用于自动推送/执行规则的hook
用于委托分级的agent
仅当确实缺少桥梁能力时使用MCP/连接器

5. Return an action-biased design

5. 输出偏向行动的设计方案

End with:

what to keep
what to suppress
what to merge
what ECC should wrap next

最终输出包含：

保留的内容
静默的内容
合并的内容
ECC下一步需要封装的能力

Output Format

输出格式

text

CURRENT SURFACE
- sources
- channels
- duplicates
- gaps

EVENT MODEL
- critical
- high
- medium
- low

ROUTING PLAN
- source -> channel
- why
- operator owner

CONSOLIDATION
- suppress
- merge
- canonical summaries

NEXT ECC MOVE
- skill / hook / agent / MCP
- exact workflow to build next