docs: salvage zh-CN business ops skill translations

docs/zh-CN/skills/brand-voice/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: brand-voice
+description: 从真实的帖子、文章、发布说明、文档或网站文案中构建基于源材料的写作风格档案，然后在内容、外展和社交工作流中重复使用该档案。当用户希望保持声音一致性而不使用通用的AI写作套路时使用。
+origin: ECC
+---
+
+# 品牌声音
+
+从真实素材中构建持久的声音档案，然后将其应用于所有场景，避免每次都重新推导风格或默认使用通用AI文案。
+
+## 何时激活
+
+* 用户希望内容或外联具有特定声音
+* 为X、LinkedIn、邮件、发布帖、推文串或产品更新撰写内容
+* 将已知作者的语调适配到不同渠道
+* 现有内容赛道需要可复用的风格体系，而非一次性模仿
+
+## 素材优先级
+
+按以下顺序使用最强真实素材集：
+
+1. 近期原创X帖子和推文串
+2. 文章、随笔、备忘录、发布说明或新闻通讯
+3. 实际有效的外发邮件或私信
+4. 产品文档、更新日志、README框架和网站文案
+
+不得使用通用平台范例作为素材。
+
+## 收集流程
+
+1. 尽可能收集5至20个代表性样本。
+2. 优先选择近期素材，除非用户明确表示旧素材更具代表性。
+3. 若素材集明显区分，将"公开发布声音"与"私下工作声音"分开处理。
+4. 若可访问实时X数据，在起草前使用`x-api`拉取近期原创帖子。
+5. 若网站文案重要，包含当前ECC落地页及仓库/插件框架。
+
+## 提取内容
+
+* 节奏与句子长度
+* 压缩与解释的平衡
+* 大小写规范
+* 括号使用方式
+* 问题频率与目的
+* 主张的尖锐程度
+* 数字、机制或实证的出现频率
+* 过渡方式
+* 作者从不使用的表达
+
+## 输出约定
+
+生成一个可复用的`VOICE PROFILE`代码块，供下游技能直接调用。使用[references/voice-profile-schema.md](references/voice-profile-schema.md)中的架构。
+
+保持档案结构化且足够简短，以便在会话上下文中复用。重点不是文学批评，而是操作复用。
+
+## Affaan / ECC 默认设置
+
+若用户需要Affaan/ECC声音且实时素材不足，除非有更新素材覆盖，否则从以下默认值开始：
+
+* 直接、压缩、具体
+* 细节、机制、实证和数字优于形容词
+* 括号用于限定、缩小范围或过度澄清
+* 大小写遵循常规，除非有真实理由打破规则
+* 问题罕见，不得用作诱饵
+* 语调可尖锐、直率、怀疑或干涩
+* 过渡应自然，而非平滑掩盖
+
+## 硬性禁止
+
+删除并重写以下内容：
+
+* 虚假好奇心钩子
+* "不是X，只是Y"
+* "无废话"
+* 强制小写
+* LinkedIn思想领袖节奏
+* 诱饵问题
+* "激动地分享"
+* 通用创始人历程填充
+* 俗气括号
+
+## 持久化规则
+
+* 在同一会话的相关任务中复用最新确认的`VOICE PROFILE`。
+* 若用户要求持久化工件，将档案保存至指定工作区位置或记忆存储区。
+* 除非用户明确要求，不得创建存储个人声音指纹的仓库跟踪文件。
+
+## 下游使用
+
+在以下场景之前或之中使用此技能：
+
+* `content-engine`
+* `crosspost`
+* `lead-intelligence`
+* 文章或发布文案撰写
+* 在X、LinkedIn和邮件上的冷启动或预热外联
+
+若其他技能已包含部分声音捕获章节，此技能为权威来源。

docs/zh-CN/skills/customer-billing-ops/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: customer-billing-ops
+description: 使用 Stripe 等连接计费工具操作客户计费工作流，例如订阅、退款、流失分类、计费门户恢复和计划分析。当用户需要帮助客户、检查订阅状态或管理影响收入的计费操作时使用。
+origin: ECC
+---
+
+# 客户计费运营
+
+此技能用于真实的客户运营操作，而非通用的支付 API 设计。
+
+目标是帮助运营人员回答：客户是谁、发生了什么、最安全的修复方案是什么、以及后续应发送什么跟进内容。
+
+## 使用场景
+
+* 客户反馈计费异常、要求退款或无法取消订阅
+* 调查重复订阅、意外扣费、续费失败或流失风险
+* 审查套餐组合、活跃订阅、年付与月付转换、或团队席位混淆
+* 创建或验证计费门户流程
+* 审计涉及订阅、发票、退款或支付方式的支持投诉
+
+## 首选工具界面
+
+* 优先使用 Stripe 等关联计费工具
+* 仅将邮件、GitHub 或问题追踪器作为辅助证据
+* 当平台已提供必要控制功能时，优先使用托管计费/客户门户而非自定义账户管理代码
+
+## 安全边界
+
+* 切勿在回复中暴露密钥、完整卡号或不必要的客户个人身份信息
+* 不要盲目退款；首先对问题进行归类
+* 区分以下情况：
+  * 意外重复购买
+  * 有意的多席位或团队购买
+  * 产品故障/价值未兑现
+  * 结账失败或不完整
+  * 因缺少自助控制功能导致的取消
+* 对于年付方案、团队方案及按比例计费状态，在操作前需核实合同结构
+
+## 工作流程
+
+### 1. 清晰识别客户身份
+
+从最可靠的标识符入手：
+
+* 客户邮箱
+* Stripe 客户 ID
+* 订阅 ID
+* 发票 ID
+* 已知可关联到计费的 GitHub 用户名或支持邮箱
+
+返回简洁的身份摘要：
+
+* 客户
+* 活跃订阅
+* 已取消订阅
+* 发票
+* 明显异常（如重复的活跃订阅）
+
+### 2. 对问题进行分类
+
+在操作前将案例归入一个类别：
+
+| 案例 | 典型操作 |
+|------|----------------|
+| 重复的个人订阅 | 取消多余订阅，考虑退款 |
+| 真实的多席位/团队意图 | 保留席位，澄清计费模式 |
+| 支付失败/结账不完整 | 通过门户恢复或更新支付方式 |
+| 缺少自助控制功能 | 提供门户、取消路径或发票访问权限 |
+| 产品故障或信任破裂 | 退款、道歉、记录产品问题 |
+
+### 3. 优先采取最安全的可逆操作
+
+推荐顺序：
+
+1. 恢复自助管理功能
+2. 修复重复或异常的计费状态
+3. 仅对受影响的扣费或重复项进行退款
+4. 记录原因
+5. 发送简短的客户跟进信息
+
+若修复需要产品工作，需区分：
+
+* 当前客户补救措施
+* 待办事项中的产品缺陷/工作流缺口
+
+### 4. 检查运营端产品缺口
+
+若客户痛点源于缺少运营界面，需明确指出。常见示例：
+
+* 无计费门户
+* 无用量/速率限制可见性
+* 无套餐/席位说明
+* 无取消流程
+* 无重复订阅防护
+
+将这些视为 ECC 或网站跟进事项，而非单纯的支持事件。
+
+### 5. 生成运营交接文档
+
+最终需包含：
+
+* 客户状态摘要
+* 已执行操作
+* 收入影响
+* 待发送的跟进文本
+* 需创建的产品或待办事项
+
+## 输出格式
+
+使用以下结构：
+
+```text
+客户
+- 姓名 / 邮箱
+- 相关账户标识
+
+计费状态
+- 活跃订阅
+- 发票或续费状态
+- 异常情况
+
+决策
+- 问题分类
+- 为何此操作正确
+
+已执行操作
+- 退款 / 取消 / 门户 / 无操作
+
+后续跟进
+- 简短客户消息
+
+产品缺口
+- 产品或网站中应修复的内容
+```
+
+## 优质建议示例
+
+* "正确的修复方案是计费门户，而非自定义仪表盘"
+* "这看起来是重复的个人结账，而非真实的团队席位购买"
+* "退还一笔重复扣费，保留剩余活跃订阅，后续如有需要再将客户转为组织计费"

docs/zh-CN/skills/email-ops/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: email-ops
+description: 以证据为先的邮箱分类、草稿、发送验证及已发送邮件安全跟进工作流，适用于ECC。当用户希望整理邮件、通过真实邮件界面起草或发送、或证明已发送邮件内容时使用。
+origin: ECC
+---
+
+# 邮件操作
+
+当实际任务为邮箱工作时使用：分类、起草、回复、发送，或确认邮件已进入已发送文件夹。
+
+这不是通用写作技能，而是围绕实际邮件界面的操作工作流。
+
+## 技能栈
+
+在相关场景下调用这些ECC原生技能：
+
+* `brand-voice` 在起草任何面向用户的内容之前
+* `investor-outreach` 用于面向投资者、合作伙伴或赞助商的邮件
+* `customer-billing-ops` 当邮件线程属于账单/支持事件而非普通通信时
+* `knowledge-ops` 当需要将消息或线程捕获到持久上下文中时
+* `research-ops` 当回复依赖最新外部事实时
+
+## 使用时机
+
+* 用户要求分类收件箱或清理低价值邮件
+* 用户需要起草、回复或发送新邮件
+* 用户想确认邮件是否已发送
+* 用户需要验证使用的账户、线程或已发送记录
+
+## 安全护栏
+
+* 除非用户明确要求实时发送，否则先起草
+* 未经真实已发送文件夹或客户端确认，不得声称邮件已发送
+* 不随意切换发件账户；选择与项目和收件人匹配的账户
+* 清理时不删除不确定的业务邮件
+* 若任务实为私信或iMessage工作，转交至`messages-ops`
+
+## 工作流程
+
+### 1. 确认具体界面
+
+操作前明确：
+
+* 哪个邮箱账户
+* 哪个线程或收件人
+* 任务是分类、起草、回复还是发送
+* 用户需要仅起草还是实时发送
+
+### 2. 撰写前阅读线程
+
+若回复：
+
+* 阅读现有线程
+* 识别最后一次对外联系
+* 识别任何承诺、截止日期或未回答问题
+
+若创建新外发邮件：
+
+* 确定亲密度等级
+* 选择正确渠道和发件账户
+* 起草前调用`brand-voice`
+
+### 3. 起草，然后验证
+
+仅起草任务：
+
+* 生成最终副本
+* 说明发件人、收件人、主题和目的
+
+实时发送任务：
+
+* 先验证最终正文
+* 通过选定邮件界面发送
+* 确认消息已进入已发送文件夹或等效的已发送副本存储
+
+### 4. 报告确切状态
+
+使用精确状态词：
+
+* 已起草
+* 待审批
+* 已发送
+* 被阻止
+* 等待验证
+
+若发送界面被阻止，保留草稿并报告确切阻止原因，而非未经说明即改用第二传输方式。
+
+## 输出格式
+
+```text
+邮件界面
+- 账户
+- 邮件线程/收件人
+- 请求的操作
+
+草稿
+- 主题
+- 正文
+
+状态
+- 已草拟/已发送/已拦截
+- 适用时附上发送证明
+
+下一步
+- 发送
+- 跟进
+- 归档/移动
+```
+
+## 常见陷阱
+
+* 未经已发送副本检查不得声称发送成功
+* 不得忽略线程历史而撰写无上下文的回复
+* 不得混淆邮箱工作与私信或短信工作流
+* 不得泄露机密、认证详情或不必要的消息元数据
+
+## 验证
+
+* 回复中指明账户和线程或收件人
+* 任何发送声明均包含已发送证明或明确的客户端确认
+* 最终状态为：已起草/已发送/被阻止/等待验证

docs/zh-CN/skills/finance-billing-ops/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: finance-billing-ops
+description: 面向ECC的以证据为先的收入、定价、退款、团队计费和计费模型真相工作流。当用户需要销售快照、定价比较、重复收费诊断或基于代码的计费现实而非通用支付建议时使用。
+origin: ECC
+---
+
+# 财务计费运营
+
+当用户想要了解资金、定价、退款、团队席位逻辑，或产品是否真的如网站和销售文案所暗示的那样运作时，使用此技能。
+
+此技能比 `customer-billing-ops` 更广泛。该技能用于客户补救。此技能用于运营者真相：收入状态、定价决策、团队计费以及基于代码的计费行为。
+
+## 技能栈
+
+在相关时，将这些 ECC 原生技能引入工作流程：
+
+* `customer-billing-ops` 用于特定客户的补救和跟进
+* `research-ops` 当竞争对手定价或当前市场证据重要时
+* `market-research` 当答案应以定价建议结束时
+* `github-ops` 当计费真相取决于兄弟仓库中的代码、待办事项或发布状态时
+* `verification-loop` 当答案取决于验证结账、席位处理或权限行为时
+
+## 使用时机
+
+* 用户询问 Stripe 销售额、退款、MRR 或近期客户活动
+* 用户询问团队计费、按席位计费或配额叠加在代码中是否真实存在
+* 用户想要竞争对手定价比较或定价模型基准
+* 问题混合了收入事实与产品实现真相
+
+## 护栏
+
+* 区分实时数据与保存的快照
+* 区分：
+  * 收入事实
+  * 客户影响
+  * 基于代码的产品真相
+  * 建议
+* 除非实际的权限路径强制执行，否则不要说“按席位”
+* 不要假设重复订阅意味着重复价值
+
+## 工作流程
+
+### 1. 从最新的计费证据开始
+
+优先使用实时计费数据。如果数据不是实时的，请明确说明快照时间戳。
+
+规范化视图：
+
+* 已付款销售
+* 活跃订阅
+* 失败或不完整的结账
+* 退款
+* 争议
+* 重复订阅
+
+### 2. 将客户事件与产品真相分开
+
+如果问题是针对特定客户的，请先分类：
+
+* 重复结账
+* 真实的团队意图
+* 自助服务控制失效
+* 未满足的产品价值
+* 付款失败或设置不完整
+
+然后将其与更广泛的产品问题分开：
+
+* 团队计费真的存在吗？
+* 席位是否实际被计数？
+* 结账数量是否会改变权限？
+* 网站是否夸大了当前行为？
+
+### 3. 检查基于代码的计费行为
+
+如果答案取决于实现真相，请检查代码路径：
+
+* 结账
+* 定价页面
+* 权限计算
+* 席位或配额处理
+* 安装与用户使用逻辑
+* 计费门户或自助管理支持
+
+### 4. 以决策和产品差距结束
+
+报告：
+
+* 销售快照
+* 问题诊断
+* 产品真相
+* 建议的运营者行动
+* 产品或待办事项差距
+
+## 输出格式
+
+```text
+快照
+- 时间戳
+- 收入 / 订阅 / 异常
+
+客户影响
+- 谁受影响
+- 发生了什么
+
+产品真相
+- 代码实际执行的操作
+- 网站或销售文案声称的内容
+
+决策
+- 退款 / 保留 / 转化 / 无操作
+
+产品差距
+- 需要构建或修复的具体后续事项
+```
+
+## 陷阱
+
+* 不要将失败的尝试与净收入混为一谈
+* 不要仅从营销语言推断团队计费
+* 在有当前证据可用时，不要凭记忆比较竞争对手定价
+* 不要在没有对问题进行分类的情况下，直接从诊断跳到退款
+
+## 验证
+
+* 答案包含实时数据声明或快照时间戳
+* 产品真相声明有代码支持
+* 客户影响与更广泛的定价/产品结论被清晰区分

docs/zh-CN/skills/google-workspace-ops/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: google-workspace-ops
+description: 将 Google 云端硬盘、文档、表格和幻灯片作为一个工作流界面来操作，用于处理计划、追踪器、演示文稿和共享文档。当用户需要查找、总结、编辑、迁移或清理 Google Workspace 资产，而无需使用原始工具调用时使用。
+origin: ECC
+---
+
+# Google Workspace 操作
+
+此技能用于将共享文档、电子表格和演示文稿作为工作系统进行操作，而不仅仅是孤立地编辑单个文件。
+
+## 使用时机
+
+* 用户需要查找文档、表格或演示文稿并进行原地更新
+* 整合存储在 Google Drive 中的计划、追踪器、笔记或客户列表
+* 清理或重构共享电子表格
+* 导入、修复或重新格式化 Google Slides 演示文稿
+* 从文档、表格或幻灯片生成摘要以供决策
+
+## 首选工具界面
+
+使用 Google Drive 作为入口，然后切换到合适的专业工具：
+
+* Google Docs 用于处理文本密集型文档
+* Google Sheets 用于表格工作、公式和图表
+* Google Slides 用于处理演示文稿、导入、模板迁移和清理
+
+不要仅凭文件名猜测结构。先检查。
+
+## 工作流程
+
+### 1. 查找资产
+
+从 Drive 搜索界面开始，定位：
+
+* 确切的文件
+* 相关资产
+* 可能的重复项
+* 最近修改的版本
+
+如果多个文档看起来相似，请通过标题、所有者、修改时间或文件夹进行确认。
+
+### 2. 编辑前检查
+
+在进行更改之前：
+
+* 总结当前结构
+* 识别标签页、标题或幻灯片数量
+* 判断任务是局部清理还是结构性调整
+
+选择能够安全完成工作的最小工具。
+
+### 3. 精确编辑
+
+* 对于文档：使用基于索引的编辑，而非模糊重写
+* 对于表格：在明确的标签页和范围内操作
+* 对于幻灯片：区分内容编辑与视觉清理或模板迁移
+
+如果请求的工作涉及视觉或布局调整，请通过检查和验证进行迭代，而不是进行一次性的盲目更新。
+
+### 4. 保持工作系统整洁
+
+当文件是更大工作流程的一部分时，还需指出：
+
+* 重复的追踪器
+* 过时的演示文稿
+* 过时文档与权威文档
+* 该资产是否应被归档、合并或重命名
+
+## 输出格式
+
+使用：
+
+```text
+资产
+- 文件名
+- 类型
+- 为何选择此文件
+
+当前状态
+- 结构摘要
+- 关键问题或阻碍
+
+操作
+- 已执行或建议的编辑
+
+后续事项
+- 归档 / 合并 / 重复清理 / 下一个待更新文件
+```
+
+## 良好用例
+
+* "找到活跃的规划文档并精简它"
+* "清理这个客户电子表格，并向我展示流失风险行"
+* "将此演示文稿导入 Slides 并使其可展示"
+* "找到当前的追踪器，而不是过时的副本"

docs/zh-CN/skills/lead-intelligence/SKILL.md

@@ -0,0 +1,323 @@
+---
+name: lead-intelligence
+description: AI原生的潜在客户情报与外联管道。取代Apollo、Clay和ZoomInfo，提供基于代理的信号评分、相互排名、温暖路径发现、来源驱动的语音建模以及跨电子邮件、LinkedIn和X的渠道特定外联。当用户想要查找、筛选并联系高价值联系人时使用。
+origin: ECC
+---
+
+# 线索情报
+
+基于智能体的线索情报管道，通过社交图谱分析与温暖路径发现，寻找、评分并触达高价值联系人。
+
+## 何时激活
+
+* 用户希望在特定行业寻找线索或潜在客户
+* 为合作、销售或融资构建外联名单
+* 研究应该联系谁以及最佳联系路径
+* 用户提及"寻找线索"、"外联名单"、"我应该联系谁"、"温暖引荐"
+* 需要根据相关性对联系人列表进行评分或排序
+* 希望绘制共同联系人图谱以寻找温暖引荐路径
+
+## 工具要求
+
+### 必需
+
+* **Exa MCP** — 用于人员、公司和信号的深度网络搜索（`web_search_exa`）
+* **X API** — 关注者/关注图谱、共同联系人分析、近期活动（`X_BEARER_TOKEN`，以及写上下文凭据，如 `X_CONSUMER_KEY`、`X_CONSUMER_SECRET`、`X_ACCESS_TOKEN`、`X_ACCESS_TOKEN_SECRET`）
+
+### 可选（增强结果）
+
+* **LinkedIn** — 如果可用则使用直接API，否则使用浏览器控制进行搜索、资料查看和消息草拟
+* **Apollo/Clay API** — 如果用户有访问权限，用于丰富化交叉引用
+* **GitHub MCP** — 用于以开发者为中心的线索资格评估
+* **Apple Mail / Mail.app** — 草拟冷邮件或温暖邮件，但不自动发送
+* **浏览器控制** — 当API覆盖不足或受限时，用于LinkedIn和X
+
+## 管道概览
+
+```
+┌─────────────┐     ┌──────────────┐     ┌─────────────────┐     ┌──────────────┐     ┌─────────────────┐
+│ 1. 信号评分  │────>│ 2. 相互排序  │────>│ 3. 发现热路径  │────>│ 4. 丰富内容  │────>│ 5. 起草外联    │
+└─────────────┘     └──────────────┘     └─────────────────┘     └──────────────┘     └─────────────────┘
+```
+
+## 外联前的语气
+
+不要从通用的销售文案中起草外联信息。
+
+当用户的语气很重要时，首先运行 `brand-voice`。在此技能中重复使用其 `VOICE PROFILE`，而不是临时重新推导风格。
+
+如果实时X访问可用，在起草前拉取最近的原创帖子。如果不可用，则使用提供的示例或最佳的仓库/网站材料。
+
+## 阶段 1：信号评分
+
+在目标垂直领域中搜索高信号人员。根据以下标准为每个人分配权重：
+
+| 信号 | 权重 | 来源 |
+|--------|--------|--------|
+| 角色/职位匹配 | 30% | Exa, LinkedIn |
+| 行业匹配 | 25% | Exa 公司搜索 |
+| 近期相关话题活动 | 20% | X API 搜索, Exa |
+| 关注者数量/影响力 | 10% | X API |
+| 地理位置接近度 | 10% | Exa, LinkedIn |
+| 与您内容的互动 | 5% | X API 互动 |
+
+### 信号搜索方法
+
+```python
+# Step 1: Define target parameters
+target_verticals = ["prediction markets", "AI tooling", "developer tools"]
+target_roles = ["founder", "CEO", "CTO", "VP Engineering", "investor", "partner"]
+target_locations = ["San Francisco", "New York", "London", "remote"]
+
+# Step 2: Exa deep search for people
+for vertical in target_verticals:
+    results = web_search_exa(
+        query=f"{vertical} {role} founder CEO",
+        category="company",
+        numResults=20
+    )
+    # Score each result
+
+# Step 3: X API search for active voices
+x_search = search_recent_tweets(
+    query="prediction markets OR AI tooling OR developer tools",
+    max_results=100
+)
+# Extract and score unique authors
+```
+
+## 阶段 2：共同联系人排名
+
+对于每个评分目标，分析用户的社交图谱以找到最温暖的路径。
+
+### 排名模型
+
+1. 拉取用户的X关注列表和LinkedIn联系人
+2. 对于每个高信号目标，检查共享联系人
+3. 应用 `social-graph-ranker` 模型来评分桥梁价值
+4. 根据以下因素对共同联系人进行排名：
+
+| 因素 | 权重 |
+|--------|--------|
+| 与目标的联系数量 | 40% — 最高权重，联系最多 = 排名最高 |
+| 共同联系人的当前角色/公司 | 20% — 决策者 vs 个人贡献者 |
+| 共同联系人的地理位置 | 15% — 同一城市 = 更容易引荐 |
+| 行业匹配 | 15% — 同一垂直领域 = 自然引荐 |
+| 共同联系人的X账号/LinkedIn | 10% — 可识别性以便外联 |
+
+规范规则：
+
+```text
+当用户需要图数学本身、作为独立报告的桥接排名或显式衰减模型调优时，使用 social-graph-ranker。
+```
+
+在此技能中，使用相同的加权桥梁模型：
+
+```text
+B(m) = Σ_{t ∈ T} w(t) · λ^(d(m,t) - 1)
+R(m) = B_ext(m) · (1 + β · engagement(m))
+```
+
+解读：
+
+* 第1层：高 `R(m)` 和直接桥梁路径 -> 请求温暖引荐
+* 第2层：中等 `R(m)` 和一跳桥梁路径 -> 有条件地请求引荐
+* 第3层：无可行桥梁 -> 使用相同的线索记录进行直接冷外联
+
+### 输出格式
+
+```
+如果用户明确要求将排名引擎单独拆分、将数学计算可视化，或在完整线索工作流之外对网络进行评分，请先独立运行 `social-graph-ranker` 作为独立步骤，然后将结果反馈回此流程。
+相互排名报告
+=====================
+
+#1  @mutual_handle (得分: 92)
+    姓名: Jane Smith
+    角色: Partner @ Acme Ventures
+    地点: San Francisco
+    与目标对象的连接数: 7
+    关联对象: @target1, @target2, @target3, @target4, @target5, @target6, @target7
+    最佳引荐路径: Jane 投资了 Target1 的公司
+
+#2  @mutual_handle2 (得分: 85)
+    ...
+```
+
+## 阶段 3：温暖路径发现
+
+对于每个目标，找到最短的引荐链：
+
+```
+你 ──[关注]──> 互关A ──[投资了]──> 目标公司
+你 ──[关注]──> 互关B ──[共同创立了]──> 目标人物
+你 ──[在]──> 活动 ──[也参加了]──> 目标人物
+```
+
+### 路径类型（按温暖度排序）
+
+1. **直接共同联系人** — 你们都关注/认识同一个人
+2. **投资组合联系** — 共同联系人投资或担任目标公司顾问
+3. **同事/校友** — 共同联系人在同一家公司工作或就读同一所学校
+4. **活动重叠** — 双方都参加了同一会议/项目
+5. **内容互动** — 目标与共同联系人的内容互动，反之亦然
+
+## 阶段 4：丰富化
+
+对于每个合格的线索，拉取：
+
+* 全名、当前职位、公司
+* 公司规模、融资阶段、近期新闻
+* 近期X帖子（最近30天）— 主题、语气、兴趣
+* 与用户的共同兴趣（共享关注、相似内容）
+* 近期公司事件（产品发布、融资轮次、招聘）
+
+### 丰富化来源
+
+* Exa：公司数据、新闻、博客文章
+* X API：近期推文、简介、关注者
+* GitHub：开源贡献（针对以开发者为中心的线索）
+* LinkedIn（通过浏览器使用）：完整资料、经历、教育背景
+
+## 阶段 5：外联草稿
+
+为每个线索生成个性化的外联信息。草稿应与来源匹配的语气配置文件和目标渠道保持一致。
+
+### 渠道规则
+
+#### 电子邮件
+
+* 用于最高价值的冷外联、温暖引荐、投资者外联和合作请求
+* 当本地桌面控制可用时，默认在 Apple Mail / Mail.app 中起草
+* 首先创建草稿，除非用户明确要求，否则不要自动发送
+* 主题行应简洁具体，不要耍小聪明
+
+#### LinkedIn
+
+* 当目标在LinkedIn上活跃、共同图谱上下文在LinkedIn上更强或电子邮件信心不足时使用
+* 如果可用，优先使用API访问
+* 否则使用浏览器控制查看资料、近期活动和起草消息
+* 保持比电子邮件更短，避免虚假的职业热情
+
+#### X
+
+* 用于高上下文的操作者、建设者或投资者外联，其中公开发帖行为很重要
+* 优先使用API访问进行搜索、时间线和互动分析
+* 必要时回退到浏览器控制
+* 私信和公开回复应比电子邮件更紧凑，并引用目标时间线上真实的内容
+
+#### 渠道选择启发式
+
+按以下顺序选择一个主要渠道：
+
+1. 通过电子邮件进行温暖引荐
+2. 直接电子邮件
+3. LinkedIn 私信
+4. X 私信或回复
+
+仅在有充分理由且节奏不会显得像垃圾邮件时使用多渠道。
+
+### 温暖引荐请求（给共同联系人）
+
+目标：
+
+* 一个明确的请求
+* 一个具体的理由说明为什么这次引荐有意义
+* 如果需要，提供易于转发的简介
+
+避免：
+
+* 过度解释您的公司
+* 堆叠社会证明
+* 听起来像筹款模板
+
+### 直接冷外联（给目标）
+
+目标：
+
+* 从具体且近期的事情开始
+* 解释为什么契合度是真实的
+* 提出一个低摩擦的请求
+
+避免：
+
+* 泛泛的赞美
+* 功能倾倒
+* 宽泛的请求，如"很乐意联系"
+* 强加的反问句
+
+### 执行模式
+
+对于每个目标，生成：
+
+1. 推荐的渠道
+2. 该渠道最佳的理由
+3. 消息草稿
+4. 可选的跟进草稿
+5. 如果电子邮件是选定的渠道且 Apple Mail 可用，则创建草稿而不仅仅是返回文本
+
+如果浏览器控制可用：
+
+* LinkedIn：查看目标资料、近期活动和共同联系人上下文，然后起草或准备消息
+* X：查看近期帖子或回复，然后起草私信或公开回复语言
+
+如果桌面自动化可用：
+
+* Apple Mail：创建包含主题、正文和收件人的草稿电子邮件
+
+未经用户明确批准，不要自动发送消息。
+
+### 反模式
+
+* 没有个性化的通用模板
+* 解释整个公司的长段落
+* 一条消息中包含多个请求
+* 没有具体细节的虚假熟悉感
+* 带有可见合并字段的批量发送消息
+* 为电子邮件、LinkedIn 和 X 重复使用相同的副本
+* 平台化的废话，而不是作者的真实语气
+
+## 配置
+
+用户应设置以下环境变量：
+
+```bash
+# Required
+export X_BEARER_TOKEN="..."
+export X_ACCESS_TOKEN="..."
+export X_ACCESS_TOKEN_SECRET="..."
+export X_CONSUMER_KEY="..."
+export X_CONSUMER_SECRET="..."
+export EXA_API_KEY="..."
+
+# Optional
+export LINKEDIN_COOKIE="..." # For browser-use LinkedIn access
+export APOLLO_API_KEY="..."  # For Apollo enrichment
+```
+
+## 智能体
+
+此技能在 `agents/` 子目录中包含专门的智能体：
+
+* **signal-scorer** — 根据相关性信号搜索和排名潜在客户
+* **mutual-mapper** — 映射社交图谱连接并寻找温暖路径
+* **enrichment-agent** — 拉取详细的个人资料和公司数据
+* **outreach-drafter** — 生成个性化消息
+
+## 使用示例
+
+```
+用户：帮我找出预测市场中我应该联系的20位顶尖人物
+
+智能体工作流程：
+1. signal-scorer 在 Exa 和 X 上搜索预测市场领导者
+2. mutual-mapper 检查用户的 X 社交图谱以寻找共同联系人
+3. enrichment-agent 提取公司数据和近期动态
+4. outreach-drafter 为排名靠前的潜在联系人生成个性化消息
+
+输出：包含热路径、语音画像摘要以及针对特定渠道或应用内草稿的排名列表
+```
+
+## 相关技能
+
+* `brand-voice` 用于规范语气捕获
+* `connections-optimizer` 用于在外联前进行先审后用的网络修剪和扩展

docs/zh-CN/skills/messages-ops/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: messages-ops
+description: 面向ECC的以证据为先的实时消息工作流。当用户想要阅读短信或私信、恢复最近的一次性验证码、在回复前检查对话线程，或证明实际检查了哪个消息来源时使用。
+origin: ECC
+---
+
+# 消息操作
+
+当任务涉及实时消息检索时使用此功能：iMessage、私信、近期一次性验证码，或后续操作前的线程检查。
+
+这不属于邮件处理。如果主要操作界面是邮箱，请使用 `email-ops`。
+
+## 技能栈
+
+在相关情况下，将这些 ECC 原生技能纳入工作流程：
+
+* `email-ops` 当消息任务实际上是邮箱操作时
+* `connections-optimizer` 当私信线程属于对外网络工作时
+* `lead-intelligence` 当实时线程应指导目标定位或预热路径外联时
+* `knowledge-ops` 当线程内容需要捕获到持久化上下文中时
+
+## 使用时机
+
+* 用户说"读取我的消息"、"查看短信"、"查看私信"或"查找验证码"
+* 任务依赖于实时线程或发送到本地消息界面的近期验证码
+* 用户希望证明检查了哪个来源或线程
+
+## 防护措施
+
+* 首先确定来源：
+  * 本地消息
+  * X/社交媒体私信
+  * 其他浏览器限制的消息界面
+* 未指明来源时，不得声称已检查线程
+* 如果存在经过检查的辅助程序或标准路径，不得自行进行原始数据库访问
+* 如果身份验证或多重身份验证阻止了界面访问，需报告确切阻碍因素
+
+## 工作流程
+
+### 1. 确定具体线程
+
+在执行任何操作之前，先确定：
+
+* 消息界面
+* 发送者/接收者/服务
+* 时间窗口
+* 任务是检索、检查还是准备回复
+
+### 2. 先读取再起草
+
+如果任务可能转为对外跟进：
+
+* 读取最新的入站消息
+* 识别未完成的环节
+* 如有需要，再移交给正确的对外技能
+
+### 3. 将验证码作为重点检索任务处理
+
+对于一次性验证码：
+
+* 首先搜索近期本地消息窗口
+* 尽可能按服务或发送者缩小范围
+* 找到验证码或重点搜索完成后即停止
+
+### 4. 报告确切证据
+
+返回：
+
+* 使用的来源
+* 尽可能提供线程或发送者
+* 时间窗口
+* 确切状态：
+  * 已读取
+  * 验证码已找到
+  * 被阻止
+  * 等待回复草稿
+
+## 输出格式
+
+```text
+来源
+- 消息界面
+- 发送者 / 线程 / 服务
+
+结果
+- 消息摘要或代码
+- 时间窗口
+
+状态
+- 已读 / 已找到代码 / 受阻 / 等待回复草稿
+```
+
+## 常见陷阱
+
+* 不要混淆邮箱操作和私信/短信操作
+* 未指明来源时，不得声称已检索
+* 当要求是查找近期验证码时，不要在广泛搜索上浪费时间
+* 不要在不报告阻碍因素的情况下反复尝试被阻止的身份验证路径
+
+## 验证
+
+* 回复中指明了消息来源
+* 回复中包含发送者、服务、线程或明确的阻碍因素
+* 最终状态明确且有边界

docs/zh-CN/skills/product-capability/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: product-capability
+description: 将PRD意图、路线图需求或产品讨论转化为可实施的方案计划，在开始多服务工作之前暴露约束、不变性、接口和未解决的决策。当用户需要ECC原生的PRD到SRS通道，而不是模糊的规划文本时使用。
+origin: ECC
+---
+
+# 产品能力
+
+该技能将产品意图转化为明确的工程约束。
+
+当问题不在于"我们应该构建什么？"，而在于"在开始实现之前，必须明确哪些条件？"时使用。
+
+## 使用时机
+
+* 存在PRD、路线图项、讨论或创始人笔记，但实现约束仍然隐式未明
+* 某个功能跨越多个服务、仓库或团队，在编码前需要一份能力契约
+* 产品意图明确，但架构、数据、生命周期或策略影响仍然模糊
+* 高级工程师在评审中反复重申相同的隐藏假设
+* 你需要一份可跨工具链和会话复用的持久化工件
+
+## 规范工件
+
+如果仓库中存在持久化的产品上下文文件，例如 `PRODUCT.md`、`docs/product/` 或程序规范目录，请在此处更新。
+
+如果尚不存在能力清单，请使用以下模板创建：
+
+* `docs/examples/product-capability-template.md`
+
+目标不是创建另一个规划栈，而是使隐藏的能力约束变得持久且可复用。
+
+## 不可妥协的规则
+
+* 不要编造产品事实。明确标记未解决的问题。
+* 将用户可见的承诺与实现细节分开。
+* 明确指出哪些是固定策略、哪些是架构偏好、哪些仍待定。
+* 如果请求与现有仓库约束冲突，请明确说明，而非粉饰太平。
+* 优先使用一份可复用的能力工件，而非零散的临时笔记。
+
+## 输入
+
+仅读取必要内容：
+
+1. 产品意图
+   * issue、讨论、PRD、路线图笔记、创始人消息
+2. 当前架构
+   * 相关仓库文档、契约、模式、路由、现有工作流
+3. 现有能力上下文
+   * `PRODUCT.md`、设计文档、RFC、迁移笔记、运营模式文档
+4. 交付约束
+   * 认证、计费、合规、发布、向后兼容、性能、评审策略
+
+## 核心工作流
+
+### 1. 重述能力
+
+将需求压缩为一个精确的陈述：
+
+* 用户或操作者是谁
+* 此功能上线后存在什么新能力
+* 因此带来了什么结果变化
+
+如果此陈述薄弱，实现将会偏离方向。
+
+### 2. 解析能力约束
+
+提取实现前必须满足的约束：
+
+* 业务规则
+* 范围边界
+* 不变性条件
+* 信任边界
+* 数据所有权
+* 生命周期转换
+* 发布/迁移要求
+* 故障与恢复预期
+
+这些往往是仅存在于高级工程师记忆中的内容。
+
+### 3. 定义面向实现的契约
+
+制定一份SRS风格的能力计划，包含：
+
+* 能力摘要
+* 明确的非目标
+* 角色与界面
+* 所需状态与转换
+* 接口/输入/输出
+* 数据模型影响
+* 安全/计费/策略约束
+* 可观测性与运维要求
+* 阻碍实现的未解决问题
+
+### 4. 转化为执行
+
+以精确的交接点结束：
+
+* 可直接实现
+* 需先进行架构评审
+* 需先明确产品细节
+
+如有帮助，可指向下一个ECC原生通道：
+
+* `project-flow-ops`
+* `workspace-surface-audit`
+* `api-connector-builder`
+* `dashboard-builder`
+* `tdd-workflow`
+* `verification-loop`
+
+## 输出格式
+
+按以下顺序返回结果：
+
+```text
+能力
+- 一段重新陈述
+
+约束条件
+- 固定规则、不变项和边界
+
+实现契约
+- 参与者
+- 界面
+- 状态与转换
+- 接口/数据影响
+
+非目标
+- 该通道明确不负责的内容
+
+待定问题
+- 仍需解决的阻碍或产品决策
+
+交接
+- 下一步应执行的操作及应由哪个ECC通道负责
+```
+
+## 良好成果
+
+* 产品意图已足够具体，无需在PR评审中重新发现隐藏约束即可实现。
+* 工程评审拥有持久化工件，而非依赖记忆或Slack上下文。
+* 生成的计划可在Claude Code、Codex、Cursor、OpenCode和ECC 2.0规划界面中复用。

docs/zh-CN/skills/product-lens/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: product-lens
+description: 使用此技能在构建前验证“为什么”，运行产品诊断，并在请求成为实施合同之前对产品方向进行压力测试。
+origin: ECC
+---
+
+# 产品透镜 —— 先思考，再构建
+
+此通道负责产品诊断，而非编写可实施的规格文档。
+
+若用户需要持久的 PRD 到 SRS 或能力契约文档，请移交至 `product-capability`。
+
+## 使用时机
+
+* 启动任何功能前 —— 验证"为什么"
+* 每周产品评审 —— 我们是否在构建正确的东西？
+* 在多个功能间难以抉择时
+* 发布前 —— 对用户旅程进行合理性检查
+* 将模糊想法转化为产品简报，并在工程规划启动前
+
+## 工作原理
+
+### 模式 1：产品诊断
+
+类似 YC 办公时间但自动化。提出尖锐问题：
+
+```
+1. 这是为谁准备的？（具体的人，而非“开发者”）
+2. 痛点是什么？（量化：频率、严重程度、当前应对方式？）
+3. 为什么是现在？（什么变化使其成为可能/必要？）
+4. 10星版本是什么？（如果资金/时间无限）
+5. MVP是什么？（能验证假设的最小方案）
+6. 反目标是什么？（明确不构建什么？）
+7. 如何判断有效？（指标，而非感觉）
+```
+
+输出：一份包含答案、风险及"可行/不可行"建议的 `PRODUCT-BRIEF.md`。
+
+若结果为"是，构建此功能"，下一通道为 `product-capability`，而非更多创始人表演。
+
+### 模式 2：创始人评审
+
+以创始人视角审视当前项目：
+
+```
+1. 阅读 README、CLAUDE.md、package.json、最近的提交
+2. 推断：这个项目试图成为什么？
+3. 评分：产品市场契合度信号（0-10分）
+   - 使用增长轨迹
+   - 留存指标（重复贡献者、回访用户）
+   - 收入信号（定价页面、计费代码、Stripe集成）
+   - 竞争护城河（什么难以复制？）
+4. 识别：能让这个项目实现10倍增长的关键因素
+5. 标记：你正在构建但无关紧要的内容
+```
+
+### 模式 3：用户旅程审计
+
+映射实际用户体验：
+
+```
+1. 以新用户身份克隆/安装产品
+2. 记录每一个摩擦点（令人困惑的步骤、错误、缺失的文档）
+3. 为每个步骤计时
+4. 与竞争对手的入门流程进行比较
+5. 评分：价值实现时间（用户需要多久才能获得首次成功？）
+6. 建议：入门流程的三大修复方案
+```
+
+### 模式 4：功能优先级排序
+
+当你有 10 个想法却需选出 2 个时：
+
+```
+1. 列出所有候选功能
+2. 对每个功能进行评分：影响（1-5）× 信心（1-5）÷ 工作量（1-5）
+3. 按 ICE 分数排序
+4. 应用约束条件：时间窗口、团队规模、依赖关系
+5. 输出：带有理由的优先级路线图
+```
+
+## 输出
+
+所有模式均输出可操作文档，而非长篇大论。每条建议均附带具体下一步行动。
+
+## 集成
+
+配合使用：
+
+* `/browser-qa` 验证用户旅程审计结果
+* `/design-system audit` 进行视觉优化评估
+* `/canary-watch` 用于发布后监控
+* `product-capability` 当产品简报需转化为可实施的能力计划时

docs/zh-CN/skills/seo/SKILL.md

@@ -0,0 +1,155 @@
+---
+name: seo
+description: 审计、规划并实施SEO改进，涵盖技术SEO、页面优化、结构化数据、核心网页指标和内容策略。当用户希望提升搜索可见性、进行SEO修复、使用架构标记、处理站点地图/robots文件或进行关键词映射时使用。
+origin: ECC
+---
+
+# SEO
+
+通过技术正确性、性能和内容相关性提升搜索可见性，而非依赖花哨手段。
+
+## 使用场景
+
+在以下情况使用此技能：
+
+* 审计爬取能力、可索引性、规范标签或重定向时
+* 优化标题标签、元描述和标题结构时
+* 添加或验证结构化数据时
+* 优化核心网页指标时
+* 进行关键词研究并将关键词映射到URL时
+* 规划内部链接或站点地图/robots文件变更时
+
+## 工作原理
+
+### 原则
+
+1. 先修复技术障碍，再进行内容优化。
+2. 每个页面应有一个明确的主要搜索意图。
+3. 优先采用长期质量信号，而非操纵性模式。
+4. 移动优先假设至关重要，因为索引基于移动端。
+5. 建议应针对具体页面且可执行。
+
+### 技术SEO检查清单
+
+#### 爬取能力
+
+* `robots.txt` 应允许重要页面并屏蔽低价值内容
+* 无重要页面被意外设置为 `noindex`
+* 重要页面应在浅层点击深度内可达
+* 避免超过两次跳转的重定向链
+* 规范标签应自洽且无循环
+
+#### 可索引性
+
+* 首选URL格式应保持一致
+* 多语言页面需正确使用hreflang（如适用）
+* 站点地图应反映预期的公开页面
+* 无重复URL在缺乏规范控制的情况下竞争
+
+#### 性能
+
+* LCP < 2.5秒
+* INP < 200毫秒
+* CLS < 0.1
+* 常见修复：预加载首屏资源、减少渲染阻塞工作、预留布局空间、精简重型JS
+
+#### 结构化数据
+
+* 首页：适当时使用组织或企业架构
+* 编辑页面：`Article` / `BlogPosting`
+* 产品页面：`Product` 和 `Offer`
+* 内部页面：`BreadcrumbList`
+* 问答部分：仅当内容完全匹配时使用 `FAQPage`
+
+### 页面规则
+
+#### 标题标签
+
+* 目标长度约50-60个字符
+* 将主要关键词或概念置于靠前位置
+* 标题应易于人类阅读，而非为搜索引擎堆砌
+
+#### 元描述
+
+* 目标长度约120-160个字符
+* 如实描述页面内容
+* 自然包含主要主题
+
+#### 标题结构
+
+* 一个清晰的 `H1`
+* `H2` 和 `H3` 应反映实际内容层级
+* 不要仅为视觉样式跳过结构层级
+
+### 关键词映射
+
+1. 定义搜索意图
+2. 收集实际的关键词变体
+3. 按意图匹配度、潜在价值和竞争程度排序
+4. 将主要关键词/主题映射到单个URL
+5. 检测并避免关键词自相残杀
+
+### 内部链接
+
+* 从权重高的页面链接到希望排名的页面
+* 使用描述性锚文本
+* 避免在可能使用更具体锚文本时使用通用锚文本
+* 从新页面补充链接到相关现有页面
+
+## 示例
+
+### 标题公式
+
+```text
+主要主题 - 特定修饰词 | 品牌
+```
+
+### 元描述公式
+
+```text
+行动 + 主题 + 价值主张 + 一个支撑细节
+```
+
+### JSON-LD示例
+
+```json
+{
+  "@context": "https://schema.org",
+  "@type": "Article",
+  "headline": "Page Title Here",
+  "author": {
+    "@type": "Person",
+    "name": "Author Name"
+  },
+  "publisher": {
+    "@type": "Organization",
+    "name": "Brand Name"
+  }
+}
+```
+
+### 审计输出格式
+
+```text
+[HIGH] 产品页面上的重复标题标签
+位置：src/routes/products/[slug].tsx
+问题：动态标题会折叠为相同的默认字符串，这会削弱相关性并产生重复信号。
+修复：使用产品名称和主要类别为每个产品生成唯一的标题。
+```
+
+## 反模式
+
+| 反模式 | 修复方法 |
+| --- | --- |
+| 关键词堆砌 | 优先为用户写作 |
+| 内容单薄的近似重复页面 | 合并或差异化处理 |
+| 为不存在的内容添加架构 | 使架构与实际内容匹配 |
+| 未检查实际页面就提供内容建议 | 先阅读真实页面 |
+| 泛泛的“改进SEO”输出 | 将每条建议与具体页面或资源关联 |
+
+## 相关技能
+
+* `seo-specialist`
+* `frontend-patterns`
+* `brand-voice`
+* `market-research`

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

@@ -0,0 +1,197 @@
+---
+name: unified-notifications-ops
+description: 将通知作为统一的 ECC 原生工作流进行操作，涵盖 GitHub、Linear、桌面提醒、钩子以及连接的通信界面。当真正的问题是告警路由、去重、升级或收件箱崩溃时使用。
+origin: ECC
+---
+
+# 统一通知运维
+
+当真正的问题不是缺少通知，而是通知系统碎片化时，使用此技能。
+
+任务是将分散的事件整合到一个操作员界面上，包含：
+
+* 明确的严重等级
+* 明确的责任人
+* 明确的路由
+* 明确的后续行动
+
+## 何时使用
+
+* 用户希望在 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 下一步应封装什么
+
+## 输出格式
+
+```text
+当前表面
+- 来源
+- 渠道
+- 重复项
+- 缺口
+
+事件模型
+- 严重
+- 高
+- 中
+- 低
+
+路由计划
+- 来源 -> 渠道
+- 原因
+- 操作员/负责人
+
+整合
+- 抑制
+- 合并
+- 规范摘要
+
+下一步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` 当通知痛点涉及计费/客户运营而非工程时