capability-distill

Capability Distill

把“为什么在两个合理选项中选择其中一个”提取成证据支持的判断规则。不要把操作步骤、通用建议或原始会话内容换个格式包装成 skill。

与现有技能的边界

• capability-distill：选择获准证据、还原决策事件、提取判断规则、输出 judgment packet。
• skill-audit：判断这些规则是否值得成为 skill、归属哪个现有 skill、是否重复以及如何分层。
• skill-creator：创建或修改具体的 SKILL.md、设计 with-skill/baseline eval、迭代和验证触发描述。
• skill-lifeguard：当产物属于高影响工作流时补可靠性契约和漂移修复闭环。

不要在本 skill 中复制后三者的完整写作、注册或评测流程。目标是提供它们可消费的高信号输入。

Operating Contract

• Direct actions: 使用当前对话和用户明确批准的本地材料；先读元数据再读内容；生成脱敏的 judgment packet；运行本地只读检查。
• Escalate before: 读取未获准的会话历史、memory、home 目录或其他仓库；把任何轨迹内容发送给外部模型；覆盖已有 skill；写入共享仓库；发布或安装产物。
• Evidence-backed pushback: 判断密度低、证据不足或已有 skill 完整覆盖时，给出具体重叠项并建议不蒸馏或只更新原 skill。
• Feedback loop: 把 eval 中的“未生效 / 机械化 / 误触发”连同对应 rule_id 回写到下一轮 judgment packet，而不是只改措辞。

0. 建立数据边界

在读取额外材料前记录以下字段：

source_scope:
  approved_roots: []
  approved_artifact_types: []
  external_model_destination:
  raw_content_authorized: false
  output_path:

当前对话和用户本次明确附带的文件可直接使用。其他路径、历史日志和 memory 不因“可能有帮助”而自动进入范围；缺少批准时先询问并暂停对应读取。

执行以下数据纪律：

• 不假定 ~/.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. 还原决策事件

从获准证据中提取事件摘要，而不是复制原文。每个事件至少包含：

decision_event:
  evidence_ref:
  context:
  viable_options: []
  chosen_option:
  observed_signal:
  outcome:
  counterfactual:
  redactions_applied: []

evidence_ref 使用本地、非敏感的定位信息，例如仓库相对路径和 commit SHA；不要把原始聊天文本塞进该字段。没有 outcome 的事件只能作为假设，不能升级为高置信规则。

3. 写作前重叠审计

在写任何 judgment_rule 前，先在 source_scope 获准的 roots 或已附 inventory 内搜索现有 rules、skills、registry 和相近 owner；先查索引和元数据，再读最可能相关的最小片段。没有获准的 owner 根目录或清单时，先请求范围并暂停规则起草，不能把“未提供”当作“无覆盖”。