Loop Discovery

---
name: loop-discovery
description: 沉淀可复用资产（skill / rule / solution / memory / 脚本）前的路由闸门：先查证据是否充分、现有覆盖是否已存在、哪个载体最小合适，输出路由结论再决定是否创建，防止资产泛滥。触发："沉淀个 skill"、"这个要不要沉淀"、"做成规则"、"loop discovery"。
---

# 沉淀路由门

## 概述

**目的**：在创建任何持久化可复用资产之前，先做一次守门检查，防止"遇到需求就新建"导致的资产泛滥、触发冲突和维护腐化

**功能**：三步路由——证据门（值不值得沉淀）→ 覆盖阶梯（现有资产能不能覆盖）→ 载体选择（沉淀成什么最合适），输出明确的路由结论

**使用场景**：
- 用户说"沉淀个 skill"、"做成规则"、"这个要不要记下来"时
- AI 解决问题后想主动沉淀经验、创建技能、写入规则时
- create-skill / solution-capture / memory-creator / expert-team 即将执行创建动作之前

## 定位

```
沉淀意图 → loop-discovery（本 skill）→ 复用现有 / 修触发 / 扩展现有
                    ↓
             新建（已选定载体）→ create-skill / solution-capture / memory-creator / create-rules / expert-team
                    ↓
             暂不沉淀 → 说明证据缺口，留观察点
```

- **输入**：沉淀意图 + 支撑证据（重复出现记录、解决过程、成本描述）
- **输出**：路由结论（复用现有 / 修触发 / 扩展现有 / 新建+载体 / 暂不沉淀）+ 理由
- **边界**：只做路由决策，不负责实际创建（创建交给下游 skill）；不负责已有资产的精简优化（那是 content-simplifier 的事）

## 何时使用

### 触发条件

| 信号 | 示例 |
|------|------|
| 显式沉淀请求 | "沉淀个 skill"、"做成规则"、"记录这个解决方案" |
| AI 主动沉淀冲动 | 解决完问题后准备调用 solution-capture / memory-creator |
| 重复工作被察觉 | "这个流程我们好像做过好几次了" |

### 不需要触发的情况

| 情况 | 处理 |
|------|------|
| 简单事实记忆（一句话偏好、路径配置） | 直接用 update_memory，不值得走路由 |
| 用户已明确指定载体且经过讨论 | 尊重用户决定，直接执行创建 |
| 对已有资产的修改、精简 | 走 content-simplifier 或直接修改 |

## 核心原则

1. **配置了 ≠ 用了**：已有资产存在不等于它在被使用，被使用不等于它有效。判断覆盖时区分这三层
2. **证据先于创建**：单次出现默认不沉淀为重资产；重复（≥2 次可比出现）或高成本才有资格新建
3. **最小载体优先**：能用一条 memory 解决的不建 rule，能扩展现有 skill 的不新建 skill
4. **暂不沉淀是合法结论**：证据不足时明确说"再观察"，比创建一个永远不会被触发的资产更好
5. **最终决定权归用户**：用户坚持要建，给出风险提示后照做

## 工作流

```
沉淀意图 → Step 1 证据门 → Step 2 覆盖阶梯 → Step 3 载体选择 → 输出路由结论
```

---

## Step 1：证据门（值不值得沉淀）

先问：支撑这次沉淀的证据是什么？

| 证据类型 | 判断标准 | 结论 |
|----------|----------|------|
| **重复出现** | 相同意图/流程在 ≥2 个不同任务中出现过（不是同一任务里重复执行） | ✅ 有资格新建 |
| **高成本单次** | 单次出现，但解决过程 ≥3 步、涉及试错/查文档，且问题可复现 | ✅ 有资格轻量沉淀（solution/memory） |
| **明确的将来需求** | 用户明确说"以后都要这样做" | ✅ 有资格新建 |
| **单次 + 低成本** | 只出现过一次，且解决不费力 | ❌ 暂不沉淀 |
| **推测性需求** | "以后可能会用到"但说不出具体场景 | ❌ 暂不沉淀，留观察点 |

**注意**：AI 自己"觉得有用"不是证据。证据必须能指向具体的任务经历或用户陈述。

## Step 2：覆盖阶梯（现有覆盖能不能满足）

证据门通过后，**按顺序**走覆盖阶梯，命中即停：

| 阶 | 检查 | 命中时的结论 |
|----|------|--------------|
| ① 已在使用的覆盖 | 现有 skill/rule/memory 已经在处理这类场景且工作正常 | **复用现有**，无需任何动作 |
| ② 平台内置能力 | AI/平台本来就会做这件事，不需要额外指导 | **不沉淀**，说明理由 |
| ③ 已配置但未触发 | 存在能覆盖的资产，但触发词不匹配 / description 不清导致没被用上 | **修触发**：改 description、补触发短语，而非新建 |
| ④ 可扩展现有 | 现有资产覆盖了大部分场景，缺的部分可作为分支/策略/子章节加入 | **扩展现有**（直接增补） |
| ⑤ 确需新建 | 以上都不满足，且证据门已通过 | **新建**，进入 Step 3 选载体 |

**检查方法**：
- 扫描 `skills/` 目录下各技能的 name + description，以及 `.solutions/INDEX.md`、`rules/`、记忆索引
- 特别警惕"功能重叠但名字不同"：新意图的描述与某个现有资产 description 高度相似时，优先走 ③ 或 ④

## Step 3：载体选择（沉淀成什么）

确需新建时，按内容形态选**最小合适载体**：

| 载体 | 适用形态 | 判断特征 |
|------|----------|----------|
| **memory**（update_memory） | 一句话事实、偏好、配置点 | 无流程、无步骤，纯陈述 |
| **rule**（rules/*.md） | 无条件约束，每次对话都要遵守 | "永远/禁止/必须"类，无触发条件 |
| **solution**（.solutions/） | 一个具体问题的解决步骤 | 问题→步骤→注意事项，场景特定 |
| **skill**（skills/） | 有触发条件的多步工作流 | 需要判断"何时用"，含决策点和输出格式 |
| **脚本**（scripts/） | 确定性操作，无需 AI 判断 | 输入输出固定，每次执行结果一致 |
| **专家资产包**（.module-experts/，由 expert-team 产出） | 某业务模块的深度领域知识 | 模块会被反复使用/排查/交接，需要契约+实现双层文档；成本最高，一次性理解需求用 module-teach 代替 |

**选择顺序**：从上往下，能用轻的不用重的。两个典型误判：
- 把"一句话经验"包装成 skill → 应该用 memory
- 把"确定性命令序列"写成 skill 步骤 → 应该用脚本，skill 最多做一层薄封装

**新建 skill 的附加要求**：给出可复述的运行契约——**何时触发（WHEN）→ 看什么输入（SEE）→ 做什么（DO）→ 怎么验证（CHECK）→ 何时停止（STOP）**。说不清 WHEN 和 CHECK 的候选退回 Step 1 补证据。

---

## 输出格式

```text
🔀 沉淀路由检查
━━━━━━━━━━━━━━━━

沉淀意图：[一句话描述]

| 检查 | 结果 | 说明 |
|------|------|------|
| 证据门 | ✅ / ❌ | [证据类型及来源] |
| 覆盖阶梯 | 命中第 N 阶 | [命中的现有资产或"无覆盖"] |
| 载体选择 | [载体] | [选择理由]（仅新建时） |

━━━ 路由结论 ━━━

[复用现有 / 修触发 / 扩展现有 / 新建 {载体} / 暂不沉淀]

[下一步动作：调用哪个 skill 或做什么修改]
```

### 结论处理

| 结论 | 下一步 |
|------|--------|
| 复用现有 | 直接使用现有资产，本次结束 |
| 修触发 | 修改现有资产的 description / 触发短语 |
| 扩展现有 | 直接在现有资产中增补 |
| 新建 skill | 调用 create-skill |
| 新建 solution | 调用 solution-capture（跳过其内部评估，路由已完成） |
| 新建 memory | 调用 memory-creator |
| 新建 rule | 调用 create-rules |
| 暂不沉淀 | 告知用户观察点："若再次出现同类场景，届时沉淀" |

---

## 示例

### 示例 1：修触发（而非新建）

```
AI 想沉淀"API 文档评审技能"

🔀 沉淀路由检查
━━━━━━━━━━━━━━━━

沉淀意图：新建 API 文档评审 skill

| 检查 | 结果 | 说明 |
|------|------|------|
| 证据门 | ✅ | 近期 3 个任务都做了 API 文档评审 |
| 覆盖阶梯 | 命中第 ③ 阶 | design-review 已支持任意格式文档评审，但 description 未提"API 文档"，导致未被触发 |

━━━ 路由结论 ━━━

修触发 — 在 design-review 的 description 中补充"API 设计文档"触发词，不新建 skill。
```

### 示例 2：暂不沉淀

```
AI 解决了一次 Docker 端口冲突后想调用 solution-capture

🔀 沉淀路由检查
━━━━━━━━━━━━━━━━

沉淀意图：记录 Docker 端口冲突解决方案

| 检查 | 结果 | 说明 |
|------|------|------|
| 证据门 | ❌ | 单次出现，解决仅 1 步（改端口映射），属常识操作 |

━━━ 路由结论 ━━━

暂不沉淀 — 解决成本低且属 AI 已有知识。若同类冲突因项目特定配置反复出现，届时再沉淀。
```

### 示例 3：新建（降级为轻载体）

```
用户："把'发版前要检查 gh CLI 认证'做成一个 skill"

🔀 沉淀路由检查
━━━━━━━━━━━━━━━━

沉淀意图：新建发版前检查 skill

| 检查 | 结果 | 说明 |
|------|------|------|
| 证据门 | ✅ | 用户明确的将来需求 |
| 覆盖阶梯 | 命中第 ⑤ 阶 | 无现有覆盖 |
| 载体选择 | memory | 内容是一句话前置条件，无多步流程，不足以支撑 skill |

━━━ 路由结论 ━━━

建议改用 memory 沉淀（project_build_configuration 类别）。
如坚持建 skill：内容过薄会导致触发价值低，确认后执行。
```

---

## 与相关 skill 的关系

| skill | 关系 |
|-------|------|
| request-guard | 平行机制：request-guard 守"修改请求"，本 skill 守"沉淀请求" |
| create-skill / solution-capture / memory-creator / create-rules | 下游执行者：本 skill 输出"新建"结论后交给它们 |
| content-simplifier | 存量治理：本 skill 只管增量入口 |
| scenario-rehearsal（skill 模式） | 事后验证：新建 skill 后可用它验证触发准确性 |

## 反模式

- ❌ **路由后又不执行**：输出"新建 skill"结论后必须衔接下游 skill，不能停在结论
- ❌ **用路由拖延明确需求**：用户已明确讨论过载体时不要再走一遍完整路由
- ❌ **把阶梯当否决器**：覆盖阶梯的目的是找最小动作，不是尽量不沉淀；证据充分且无覆盖时应果断新建
- ❌ **跳过扫描凭印象判断**：第 ② ③ ④ 阶必须实际查看现有资产的 description，不能凭记忆断言"没有覆盖"