메뉴
Scope Guard + Process Evolution + Knowledge Evolution — 主动护栏与自我进化。 Use when: operator scope 发散偏离愿景、同类错误反复出现、SOP 流程缺口、有价值的知识/方法论值得沉淀。 Not for: 日常 SOP 推进（正常执行）、一次性个案 bug fix。 Output: Scope Guard Log 记录 / Evolution Proposal 提案 / Episode Card → Method/Skill 蒸馏 → Eval 验证。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
约定图发现方法论：进一个 repo 先识别 repo-specific conventions，再定义 domain/extractor 接 Convention Graph 引擎。Use when: 进入陌生 repo、要画约定图、要找“改 X 影响谁”的约定层关联、 F242/Convention Graph Layer 工作。Not for: 普通符号跳转/LSP、文档索引检索、记忆图谱、直接使用 codegraph/GitNexus。Output: domain 定义 + extractor 计划 + gap/freshness/provenance 报告。 GOTCHA: 沉淀的是“怎么画图”的方法，不是把 cat-cafe 的 extractor 硬搬到所有 repo。
跨 thread 协同：发现平行 session → 通知（3+2 件套）→ 争用协调 → 确认。 Use when: 平行 session 之间需要协同、收到跨线程消息、通知改动影响、共享文件争用。 Not for: 跨猫工作交接（用 cross-cat-handoff）、需要新建 thread 时（用 propose_thread / thread-orchestration）。 GOTCHA: 收到跨线程 ACTION 不等于接活；先做 thread/feat ownership gate，不属于当前 thread 就 cross-post 退回。 Boundary with F128: 发现跨 scope 问题 → 先 list_threads 查有没有已有 thread → 有 = 本 skill（cross_post）→ 没有 = propose_thread。 Output: cross-post 通知 + 争用协调完成。
Feature 立项、讨论、完成的全生命周期管理。 Use when: 开个新功能、new feature、F0xx、立项、feature 完成、验收通过、讨论新功能需求。 Not for: 代码实现、review、merge（那些有专门的 skill）。 Output: Feature 聚合文件 + BACKLOG 索引 + 真相源同步。
明星开源项目拆解：从宣传/PPT/README 进入源码，验证真实架构、明星特性、算法含量、营销水分、可学习点和不 follow 的 tradeoff。 Use when: operator要求拆解热门 GitHub 项目、竞品 agent/runtime、外部 skill/tool 框架，或问“它到底有什么真本事/我们能学什么”。 Not for: 普通资料搜索（用 deep-research）、社区 issue/PR 运营（用 opensource-ops）、只需要架构头脑风暴（用 collaborative-thinking）。 Output: feature-discussions/YYYY-MM-DD-{project}-deep-dive/ 下的代码证据报告 + 对比结论 + 候选 lesson/skill。 GOTCHA: 不许只看 README 下判断；每个明星特性必须追到代码路径、状态突变点、反馈闭环和算法输入输出。
开发完成后的自检门禁：愿景对照 + spec 合规 + 验证。 Use when: 开发完了准备提 review、声称完成了、准备交付。 Not for: 收到 review 反馈（用 receive-review）、merge（用 merge-gate）。 Output: Spec 合规报告（含愿景覆盖度）。
接球前真相核验三问：claim → resolver → verdict (sourceTier T0/T1/T2 + actionFamily)， 防止把传球者当无审视真相源（F167 Phase O 第一性原理）。 Use when: 即将调 hold_ball / register_pr_tracking / register_issue_tracking / merge / takeover / 改 owner / 任何 irreversible action / 基于 "operator signoff" 或 "你是 owner" 类 claim 行动之前。 Not for: 纯阅读 cross_post（无 actionFamily 后续）；本 thread 日常 @mention 无副作用； implementation continuation（自检通过的下一步）。 Output: claim grounding verdict (verified/mismatch/insufficient) + 接球决策 (proceed / block / push back to source thread)。
| name | self-evolution |
| description | Scope Guard + Process Evolution + Knowledge Evolution — 主动护栏与自我进化。 Use when: operator scope 发散偏离愿景、同类错误反复出现、SOP 流程缺口、有价值的知识/方法论值得沉淀。 Not for: 日常 SOP 推进（正常执行）、一次性个案 bug fix。 Output: Scope Guard Log 记录 / Evolution Proposal 提案 / Episode Card → Method/Skill 蒸馏 → Eval 验证。 |
三猫共用。猫猫是主动的共创伙伴（P2），不是被动的 agent。 发现问题就护栏，发现规律就改进，发现知识就沉淀。 闭环 = 触发→产出结构化记录→蒸馏复用资产→验证净增益→五级阶梯治理。
| 模式 | 方向 | 保护/推动什么 | 触发 | 产出物 |
|---|---|---|---|---|
| A: Scope Guard | 防御 | 当前 feat 验收边界 | operator讨论偏离愿景 | Scope Guard Log 记录 |
| B: Process Evolution | 防御→改进 | 团队流程持续改进 | 重复犯错 / 流程缺口 | Evolution Proposal |
| C: Knowledge Evolution | 进攻→成长 | 团队能力边界扩展 | 有价值的知识/方法论产生 | Episode Card → Method/Skill |
不靠机械计数。看是否越过当前 feat 契约——满足 2 个普通信号或 1 个强信号：
| 信号 | 强度 |
|---|---|
| 新想法不直接服务当前愿景/验收条件 | 普通 |
| 新想法引入新的用户旅程/新页面/新子系统 | 强 |
| 新想法需要新的外部依赖/API/数据模型 | 强 |
| 新想法导致"这次怎么验收"说不清了 | 强 |
operator，先收一下：当前 feat 愿景是 {愿景}。刚才提到的 {新方向} 更像独立 feat / 下一 phase。要不要拆出去方便验收？
每次触发后追加到 docs/scope-guard-log.md：
| {date} | {feat_id} | {signal_type} | {action_taken} | {outcome} | {agent} |
docs/evolution-proposals/TEMPLATE.md 创建 EP-XXX.md复述scope → 改memory → 改单skill → 改SOP/shared-rules → 改SystemPromptBuilder → 改L0
被纠正不丢人，不记录才丢人。
operator的自然语言纠正——不需要精确匹配，识别意图即可：
检测到纠正信号后，先完成operator实际要求的任务，然后在同一轮回复末尾附一段 evidence 记录到 F167 spec（docs/features/F167-a2a-chain-quality.md 的 Behavioral Evidence 区）：
### Case E{N}: {一句话标题}（{日期}）
| 维度 | 内容 |
|------|------|
| 我以为 | {我理解的任务} |
| 实际要求 | {operator实际要的} |
| 偏差根因 | {任务替换 / 锚定偏差 / 行动偏好 / 上下文盲视 / ...} |
| 纠正轮次 | {被纠正几次才理解} |
| 元心智哪条没执行 | {Q1角色确认 / Q2信息验证 / Q3坐标变换 / 都执行了但仍偏} |
不只从错误中学习，也从有价值的经验中成长。 三机制闭环：Episode Card（原料）→ Dual Distillation（蒸馏成品）→ Eval Ledger（证明净增益）
问三个问题：
三个中满足 ≥ 2 个 → 值得沉淀。
高价值协作后写结构化事件快照。用 docs/episodes/TEMPLATE.md 创建。
触发条件（满足任两条）：
Episode Card 必须包含：
每张 Episode Card 蒸馏成两种形态之一：
| 条件 | 蒸馏成 | 模板 |
|---|---|---|
| 高风险/跨领域分析框架 | Method Card | docs/methods/TEMPLATE.md |
| 重复步骤稳定的流程型任务 | Skill Draft | 走 writing-skills skill |
Replay A/B 验证知识净增益。用 evals/mode-c/TEMPLATE/ 结构创建。
A/B 卫生规则：
Case 数量：
Judge 评分维度：
| 维度 | 权重 |
|---|---|
| Boundary compliance | 35% |
| Evidence handling | 30% |
| Knowledge application | 20% |
| Human edit volume | 15% |
详见 ADR-015。三模式产出物共享同一套阶梯。
| Level | 形态 | 晋升条件 |
|---|---|---|
| L0 | Episode | 模板完整，已分离可迁移/不可迁移 |
| L1 | Pattern | ≥2 个相似 episode（180 天内），或人类要求；5Q ≥ 7/10 |
| L2 | Draft | smoke gate ≥3 cases（≥2/3 pass）；promotion gate ≥5 cases（≥3/5 pass，覆盖 3 类） |
| L3 | Validated | ≥6 uses，≥2 agents，≥80%，无 critical breach |
| L4 | Standard | ≥12 uses，最近 10 次 ≥90%，operator 批准 |
双车道：long_tail: true 允许长期停 L2/L3（高风险/低频域）。
| 层级 | 角色 | 禁止 |
|---|---|---|
| Episode | 个案级证据底稿（原料） | — |
| Method / Skill | 蒸馏后的复用资产（成品） | — |
| memory | 轻量索引/指针 | 禁止复制 Method 正文 |
| lessons-learned | 失败导向教训库 | 禁止塞入成功案例 |
三信号路由——不信单次口头自信度：
| 信号 | 来源 |
|---|---|
| domain_reliability | 滚动域内可靠度 (successes+1)/(trials+2) |
| evidence_completeness | 证据覆盖度评估 |
| self_reported_confidence | 自报置信度（参考但不依赖） |
高风险域 action_confidence < 0.85 → 只做结构化分析 + 明确升级，不给结论。
knowledge frontmatter 块（ADR-015）collaborative-thinking：讨论收敛用它；scope 漂/犯错/知识沉淀 → self-evolutiondeep-research：调研过程用它；调研产出有复用价值 → Mode Cdebugging：定位 bug 用它；同类 bug 反复 → Mode Bwriting-skills：写 skill 用它；Mode C 蒸馏出 Skill Draft → writing-skills 接手三个模式出口都一样：闭环后回到当前工作。