症状

在 312 个 session 的使用数据中，Skill agent 仅被触发 1 次，触发率 0.3%。与此同时，behavioral-skill-recommendation.md 规则明文规定：

当用户提出修复请求或项目需求时，必须主动推荐最合适的 skill

规则存在，触发率却接近于零。这不是「规则不够」，而是更深层的问题。

诊断

经过多次 Debug 追踪，发现问题的根本原因：规则是「事后拦截」而非「事前检查」。

当用户说「修一个 bug」，Claude 的执行路径是：

1. 直接动手修改代码
2. 修复完成后，才想起应该检查是否有匹配的 Skill
3. 此时工作已做完，Skill 调用变成了「马后炮」

规则写在文件里，但 没有任何机制在动手之前触发它。这是一个典型的「最后一公里」问题——知道应该做，但无法在正确的时间点想起。

三层防御

为了解决这个问题，需要在不同的时机点建立强制检查点：

第一层：PreToolUse Hook（系统强制）

通过 OMC 系统层的 Hook，在每次执行 Edit/Write/Bash 之前注入检查逻辑。这是物理阻断层，无法绕过。

// PreToolUse Hook 示例
if (tool === 'Edit' || tool === 'Write') {
  // 检查是否有匹配的 Skill 场景
  // 如果有，强制推荐而非直接执行
}

第二层：Pre-Action Gate（行为约束）

在 behavioral-skill-recommendation.md 中增加「行动前强制自检」：

PRE-ACTION CHECK:
  1. 我调用这个工具的依据是什么？
  2. 我有没有想起来应该用 Skill？
  3. 如果答案是「在猜」或「不确定」→ 立即调用匹配的 Skill

这不是建议，而是强制行为约束。

第三层：肌肉记忆（输出格式）

要求每次调用 Skill 前必须输出调用理由：

[Skill 调用] 调用 ecc:build-error-resolver
原因：astro build 报错，需要专业化诊断而非猜测
置信度：高

通过格式化的输出，建立「先思考再调用」的肌肉记忆。

核心教训

知道规则存在 ≠ 在正确时机调用规则。

一个规则如果不配套「何时触发」的机制，它就只是一段文字，而不是约束。规则体系需要：

1. 触发时机明确：规则文件本身说明「在 X 情况下检查」
2. 物理阻断：通过 Hook 或 Gate 在关键路径上拦截
3. 输出格式化：通过标准输出格式建立习惯

312 sessions 只触发 1 次 Skill，不是规则写得不够详细，而是缺少一个在动手之前能够被调用的触发器。

三层防御系统的核心思想：在正确的时间点，以正确的方式，提醒我做正确的事。