110 added, 67 removed. Audit A to A.
---
name: capability-distill
- description: 能力蒸馏工作流——把强模型（限时窗口的新模型）或高质量轨迹中的判断力，蒸馏成弱模型/日常模型可加载的判断层 skill。当用户说"蒸馏"、"把 X 模型的能力写成 skill"、"新模型窗口要关了帮我留点东西"、"这次任务做得好把方法固化下来"时使用。产出的是判断手册（怎么想、何时停），不是操作规程。
+ description: 能力蒸馏工作流——从用户批准的强模型访谈或真实任务轨迹中提取非显然的判断规则，形成可审计的 judgment packet，再交给 skill-audit 和 skill-creator 决定是否落成可加载 skill。当用户说“蒸馏这个模型的判断力”“把这次任务的关键决策固化下来”“模型窗口要关了，保留它在某类场景的判断”时使用。普通流程文档、直接写 SKILL.md、泛化最佳实践或未授权的会话日志扫描不使用本 skill。
---
- # Capability Distill — 能力蒸馏工作流
+ # Capability Distill
- > 由 Fable 5 在 2026-07 高额度窗口期间实践并复盘固化。
- > 核心命题：模型访问是租来的，蒸馏出的判断层 skill 是自己的。
- > 两种触发场景：**窗口蒸馏**（强模型限时可用，让它蒸馏自己）；**轨迹蒸馏**（某次任务完成得特别好/特别差，把决策方式提取出来，不需要强模型在场）。
+ 把“为什么在两个合理选项中选择其中一个”提取成证据支持的判断规则。不要把操作步骤、通用建议或原始会话内容换个格式包装成 skill。
+ ## 与现有技能的边界
+
+ - `capability-distill`：选择获准证据、还原决策事件、提取判断规则、输出 judgment packet。
+ - `skill-audit`：判断这些规则是否值得成为 skill、归属哪个现有 skill、是否重复以及如何分层。
+ - `skill-creator`：创建或修改具体的 `SKILL.md`、设计 with-skill/baseline eval、迭代和验证触发描述。
+ - `skill-lifeguard`：当产物属于高影响工作流时补可靠性契约和漂移修复闭环。
+
+ 不要在本 skill 中复制后三者的完整写作、注册或评测流程。目标是提供它们可消费的高信号输入。
+
## Operating Contract
- - Direct actions: 从使用痕迹提取场景清单、做重叠审计、起草判断层 skill 文件、跑废话检测三关、生成验证行为检查项。
- - Escalate before: 覆盖/删除已有 skill 或规则文件、把蒸馏产出提交到共享仓库、砍掉用户明确要求保留的场景。
- - Evidence-backed pushback: 场景判断密度低或已有覆盖高时，明确建议不蒸馏并给出依据，而不是照单全做。
- - Feedback loop: 第 5 步验证协议的逐条"生效/未生效/机械化"记录回流到 skill 修订。
+ - Direct actions: 使用当前对话和用户明确批准的本地材料；先读元数据再读内容；生成脱敏的 judgment packet；运行本地只读检查。
+ - Escalate before: 读取未获准的会话历史、memory、home 目录或其他仓库；把任何轨迹内容发送给外部模型；覆盖已有 skill；写入共享仓库；发布或安装产物。
+ - Evidence-backed pushback: 判断密度低、证据不足或已有 skill 完整覆盖时，给出具体重叠项并建议不蒸馏或只更新原 skill。
+ - Feedback loop: 把 eval 中的“未生效 / 机械化 / 误触发”连同对应 `rule_id` 回写到下一轮 judgment packet，而不是只改措辞。
- ## 第 0 步：确认蒸馏的是判断不是流程
+ ## 0. 建立数据边界
- 先做一个分类判断，分错这一步后面全废：
+ 在读取额外材料前记录以下字段：
- - **流程**（可写成步骤/命令/checklist 的）→ 不走本工作流，直接写成普通操作 skill 或 hook。
- - **判断**（需要现场权衡的：查哪层、何时停、信谁的证据、要不要拆）→ 本工作流的对象。
- - 判断的识别特征：两个都合理的选项之间选择、依赖上下文的阈值、"什么时候例外"的知识。
+ ```yaml
+ source_scope:
+ approved_roots: []
+ approved_artifact_types: []
+ external_model_destination:
+ raw_content_authorized: false
+ output_path:
+ ```
- ## 第 1 步：场景清单（从使用痕迹来，不从记忆来）
+ 当前对话和用户本次明确附带的文件可直接使用。其他路径、历史日志和 memory 不因“可能有帮助”而自动进入范围；缺少批准时先询问并暂停对应读取。
- **不要问用户"你有什么场景"**——人对自己最高频的判断习以为常，列不出来。从实际痕迹提取：
+ 执行以下数据纪律：
- ```bash
- ls -lt ~/.claude/skills/ | head -30 # 最近在建/改什么 skill
- ls <项目根>/.. # 活跃项目和 worktree 分布
- # 可选：会话历史、memory 文件、git log 近期主题
+ - 不假定 `~/.claude`、`~/.codex` 或任何固定运行时路径存在。使用用户给出的路径、当前工作区和当前运行时可用的搜索工具。
+ - 先查看文件名、时间、提交主题等元数据，只对候选决策事件读取最小必要片段。
+ - 不把 token、密钥、cookie、个人身份信息、客户数据、私有源码或完整 prompt/response 写入 packet 或 eval。
+ - 如需外部强模型，只发送经用户批准的脱敏场景摘要；没有目标模型和数据发送授权就标记阻塞，不假装完成窗口蒸馏。
+ - provenance 只写可验证的来源标签和日期。模型名、版本或作者未知时留空，不猜测。
+
+ ## 1. 判断是否适合蒸馏
+
+ 先区分对象：
+
+ - 可由固定命令或 checklist 完成的是流程，交给 `skill-audit` / `skill-creator`，不做判断蒸馏。
+ - 需要根据上下文在多个合理选项间权衡，并且存在切换、停止或上抛信号的，才是候选判断。
+ - 只包含“谨慎、验证充分、保持简洁”等通用态度时，直接判为低判断密度。
+
+ 对候选场景记录 `judgment_density`、`evidence_strength` 和 `existing_coverage`（high / medium / low）。只保留判断密度高、证据至少中等且现有覆盖不完整的场景。
+
+ ## 2. 还原决策事件
+
+ 从获准证据中提取事件摘要，而不是复制原文。每个事件至少包含：
+
+ ```yaml
+ decision_event:
+ evidence_ref:
+ context:
+ viable_options: []
+ chosen_option:
+ observed_signal:
+ outcome:
+ counterfactual:
+ redactions_applied: []
```
- 对每个候选场景打两个分（高/中/低）：
- - **判断密度**：这个场景的质量差异来自判断力还是执行力？
- - **现有覆盖**：已有 skill/规则把它流程化到什么程度？
+ `evidence_ref` 使用本地、非敏感的定位信息，例如仓库相对路径和 commit SHA；不要把原始聊天文本塞进该字段。没有 outcome 的事件只能作为假设，不能升级为高置信规则。
- 只蒸馏"判断密度高 + 现有覆盖低"的场景。判断密度低的不值得，现有覆盖高的蒸不出增量。把清单和排序展示给用户确认，用户常会砍掉或合并——这一步的讨论本身会暴露真正的痛点。
+ ## 3. 提取隐性判断
- ## 第 2 步：重叠审计（写作前的强制步骤）
+ 窗口蒸馏时，对每个脱敏场景逐个询问强模型：
- ⚠️ 这是最容易翻车的一步：蒸馏产出如果和现有规则集（CLAUDE.md、VibeGuard 类规则、既有 skill）重复，就制造了双真实来源，且消耗约束预算。
+ - 行为差异首先出现在哪个决策点？
+ - 哪个可观察信号会切换策略、停止或上抛？
+ - 最像成功的失败状态是什么，如何识别？
+ - 默认规则在哪些条件下应被违反？
- - 列出目标场景相关的所有现有规则/skill，逐条标注：已覆盖 / 部分覆盖 / 未覆盖。
- - 新 skill **只写"未覆盖"栏**；与"部分覆盖"衔接处用一句话引用（"X 见规则 Y，本文只补 Z"），不复述原文。
- - 在新 skill 的开头声明与现有体系的分工边界。
+ 轨迹蒸馏时，围绕已有事件回答相同问题，并比较成功与失败轨迹。不要让模型“一次写完整指令体系”；那会掩盖证据和规则之间的映射。
- ## 第 3 步：蒸馏写作协议
+ ## 4. 生成 judgment packet
- ### 窗口蒸馏（强模型在场）
+ 每条规则使用以下结构：
- 不要只说"写一套指令"。用**具体场景提问**逼出隐性判断，逐场景问强模型：
+ ```yaml
+ judgment_rule:
+ rule_id:
+ scenario:
+ observable_signal:
+ default_action:
+ exception:
+ stop_or_escalate:
+ evidence_refs: []
+ confidence:
+ open_questions: []
+ ```
- - "在这个场景里，你和一个较弱模型的行为差异具体出现在哪个决策点？"
- - "你在什么信号下会切换策略/停止/上抛？阈值是多少？"
- - "这个场景里最常见的假成功长什么样？你怎么识别？"
- - "有哪条你遵守但从没被明说的纪律？"
+ 规则不得包含源材料中的秘密值或大段原文。`confidence` 由证据数量、结果可观察性和反例覆盖决定；单一无结果片段不能标 high。
- ### 轨迹蒸馏（从已完成的任务提取）
+ ## 5. 去除泛化废话
- 对着轨迹问：这次的关键转折点在哪？当时有哪些备选方向、为什么选了这个？哪一步如果做错整个任务就偏了？失败轨迹同样蒸馏：决策边界在失败里比在成功里更清晰。
+ 逐条运行三关，并记录被删除的 `rule_id` 与原因：
- ### 写作规格
+ 1. 反转测试：反过来说若明显荒谬，原句通常没有信息量。
+ 2. 新手测试：无该领域经验的合格工程师也会自然做到，则不值得蒸馏。
+ 3. 可违反测试：无法构造一个可观察的违反场景，则规则太抽象。
- - 每份一个场景，100-150 行，结构：本场景的本质特征 → 关键决策点的判断标准 → 证据/质量纪律 → **场景特有的停止/上抛信号**（必须有，这是弱模型差距最大的地方）。
- - 每条判断尽量配**可观察的触发信号或机械检查**（"豁免清单超过 5 项 → 重新设计"），纯态度性表述（"要谨慎"）不许出现。
+ 规则通过三关仍需具备 `observable_signal`、`exception` 和 `stop_or_escalate`；缺一项就返回提取阶段，不用“按情况判断”填空。
- ## 第 4 步：废话检测（发布前的质量门）
+ ## 6. 重叠审计与实现交接
- 蒸馏的头号失败模式是产出**弱模型本来就会写的通用建议**。逐行过三个删除标准：
+ 把 packet 交给 `skill-audit`，要求它对每条规则标注：`existing_owner`、`coverage`、`recommended_home`。完整覆盖的规则删除；部分覆盖的规则优先更新原 skill；只有明确无归属的高信号规则才进入新 skill brief。
- 1. **反转测试**：把这条判断反过来说，是否明显荒谬？"验证要充分"反过来荒谬 → 是废话，删。"从证据密度最高的层开始查，而不是怀疑最大的层"反过来（从怀疑最大的开始）是很多人的真实做法 → 有信息量，留。
- 2. **新手测试**：一个没做过这类任务的合格工程师，会自己想到这条吗？会 → 删。
- 3. **可违反测试**：能构造一个具体场景，某人违反了这条且能被指出来吗？不能 → 太抽象，改具体或删。
+ 用户要求可加载 skill 时，再调用 `skill-creator`：
- 三关过完通常会删掉 30-50% 的初稿。删不动说明第 3 步提问不够具体，回去重问。
+ 1. 以通过审计的 packet 为输入，不重新发明规则。
+ 2. 用 `skills/capability-distill/evals/evals.json` 中的边界场景作为最低测试集，并为目标领域增加真实、脱敏场景。
+ 3. 同时运行 with-skill 和 baseline/old-skill，对比可观察行为，不以“文字更好看”判定成功。
+ 4. 高影响工作流再交给 `skill-lifeguard` 检查负例、checkpoint、done condition、replay hook 和 drift signal。
- ## 第 5 步：验证协议（在目标模型上）
+ ## Done When
- skill 不经真实任务验证就是装饰品。窗口关闭后，在目标模型上：
+ `packet_only` 仅在以下条件全部满足时完成：
- 1. 每个场景挑 1-2 个**真实任务**（不是构造的玩具任务），开头显式加载对应 skill。
- 2. 验证看的是**可观察行为**，不是产出质量的整体感觉。写 skill 时就为每条关键判断定义行为检查项，例如：
- - 排障 skill → 它有没有在动手前先回答影响面三问？
- - 长时程 skill → 会话结束时有没有主动留接续锚点？
- - 有没有在该停止的信号出现时真的停止上抛？
- 3. 逐条记录：生效 / 未生效 / 生效但机械化（照念条文没做判断）。
- 4. **未生效的条目**，先怀疑写得太抽象（改成更机械的触发条件），再怀疑目标模型 instruction-following 上限（改成 hook 强制），最后才删。
- 5. 迭代 2-3 轮后收敛。"生效但机械化"的条目是正常状态——蒸馏传递的本来就是显式决策规则，不是隐式能力，别追求完美复刻。
+ - `source_scope` 已记录，所有读取和外部发送均在批准范围内。
+ - 输出不含原始秘密、个人数据、客户数据或大段轨迹原文。
+ - 每条保留规则都能追溯到至少一个 `decision_event`，并具有信号、默认动作、例外和停止/上抛条件。
+ - 三关删除记录存在，未知信息留空或列入 `open_questions`。
+ - `skill-audit` 已给出保留、更新现有 skill 或不创建的归属结论。
- ## 第 6 步：生命周期
+ `skill_delivery` 还必须满足：
- - 每份蒸馏 skill 标注来源和日期（"Fable 5 蒸馏，2026-07"）——将来更强的模型可用时，同场景**重新蒸馏并对比 diff**，diff 本身能看出模型判断力进化在哪。
- - 目标模型换代后重跑第 5 步：新模型可能原生具备某些条目，那些条目删掉（skill 里只留目标模型仍不具备的判断）。
- - 与已有的蒸馏手册同场景时，更新旧文件而不是新建。
+ - `skill-creator` 的真实 with-skill/baseline eval 已运行并保存结果。
+ - 至少一个近边界负例证明普通流程请求不会误用本 skill。
+ - registry/质量/测试命令按目标仓库要求 fresh 通过；无法运行的检查明确标记 blocker。
- ## 反模式清单
+ ## Gotchas
- - 让强模型"写一套完整指令体系"一把梭 → 产出泛泛的 8 条通用建议，全是废话检测该删的。
- - 跳过重叠审计 → 和现有规则集重复，双真实来源 + 约束预算爆炸。
- - 蒸馏流程性知识（部署步骤、查询命令）→ 那是操作 skill 的事，判断手册写这些会又长又没重点。
- - 用构造任务验证 → 构造任务天然贴合 skill 条文，测不出真实迁移效果。
- - 把"目标模型没完美执行"当成蒸馏失败 → 捕获 60-70% 的显式判断已经是巨大收益，剩下的是模型能力差距不是 skill 问题。
+ - 扫描整个 home 目录不是“场景发现”，而是未经授权的数据扩大；改为批准范围内的元数据优先检索。
+ - “来自某强模型”不是证据。没有 decision event 和 outcome 的内容只能是待测假设。
+ - 新建文件比更新旧文件更容易，但 overlap high 时必须更新现有 owner。
+ - 构造任务常会迎合规则；eval 至少包含真实脱敏任务和一个容易误触发的近边界请求。