# Rule Enforcement

> Use when 规范执行失败/被质疑/自查/反思复盘规范执行——先加载归因再修。

- Skill: `yyyyyhhhhh0639/rule-enforcement` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add yyyyyhhhhh0639/rule-enforcement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yyyyyhhhhh0639/rule-enforcement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: yyyyyhhhhh0639 (https://skillmd.com/u/yyyyyhhhhh0639)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/yyyyyhhhhh0639/rule-enforcement

---


# 规范执行 (Rule Enforcement) — 元层诊断

## 收敛层定位（2026-08-04 固化）

本技能是规范体系的**最后一层**——向下不建"元元层"，没有技能管本技能的执行。（"描述 ≠ 管"：references/ 等描述性文档组织已有规范，不构成"管本技能的执行"——不归因、不监督、不选修复手段）

- **正确用法**：诊断失败实例 → 把规范**折叠进现有执行点**（流程步骤/模板/checklist），让执行靠流程推进而非靠"记得加载本技能"（记忆锚点/环境提示属**触发补强**——靠注入层可见性，不是事后回忆，不算"靠记得"）
- **错误用法**：把本技能当作再建规则的理由（"rule-enforcement 说要管规范 → 再建一个规范技能"= 嵌套地狱）
- **自指约束**：本技能自身的应用失败（如"忘记加载本技能"）同样是 L1 实例——用同一套模型归因，不需要第二层监督
- **数量红线**：规范执行准确率与规则数量**负相关**；评估任何新规范先问"能折叠进现有执行点吗？"——不能则大概率不该建
- **越界信号（二维判定，2026-08-05 修正）**：
  - **性质维度**——新建**规范性**文档（规则/管理逻辑/监督 RE 的技能）→ 越界，折叠更深；新建**描述性**文档（地图/索引，如 references/governance-architecture.md）→ 合法（不归因不监督）
  - **使用维度**——任何文档被**当作规范引用**（"文档说 X，所以必须 X"）→ 越界滑坡；缓解：描述性文档显式声明"地图非规则" + 引用时检查声明（与"本体 vs 索引摘要"同一判别机制）

## When to Use

- 用户质疑"你没遵守规范/规则/约定"
- 自查发现应用失败（规范存在但没执行）
- 需要决定"规范为什么没执行 + 怎么修"（不是"再加一条规则"）
- 讨论规范体系本身的改进方向

## 核心模型：L0 / L1 两类归因（2026-08-04 修正版）

应用失败**只有两类根因**，四实例全部收敛于此（创建会话中用户质疑后修正）：

| 类 | 机制 | 典型实例 | 修复手段 | 信号 |
|----|------|---------|---------|------|
| **L0 结构性** | 规则不可达（工具/系统层缺陷，提示词层免疫） | search_files 工具把 `F:\` 转 `/f/` 给 native rg | **工具层修复**（patch 源码/配置），写规则无效 | 换了正确写法仍然失败；错误发生在工具内部 |
| **L1 无意识遗忘** | 规则存在但**决策时刻未检索**（默认行为路径） | native 传 `/f/`、记忆判据未加载、lens 实证未分层 | **降低"依赖记得"**：触发条件补强 / 判据流程化 / 操作化清单 / 主动前置 | 事后复盘"其实我知道这条规则" |

**关键推论：**
- 主战场是 **L1**（四实例中三例同属此类）——问题不是规则缺失，是**加载失败**
- **"有意识违规"几乎不存在**——违规本身即证明决策时刻未应用规则；事后引用规则是"追认"，不是"明知故犯"（判定：违规发生在引用之前 → L1）
- L0 是少数派，但修规则对它无效——先判别再选手段，避免"L0 问题用 L1 手段修"（写了规则也没用）

**执行偏差的性质**：
- 执行偏差是规范体系故障的**信号**，不是规范文本故障的**证明**——先归因，再修对应层
- 每个偏差必须**个体归因**（不能默认 L1，也不能默认文本问题）；归因前禁止直接修文本
- **规范设计定义**：规范设计 = 文本 + 操作化 + 流程化 + 触发补强——评价标准是**减少执行偏差**，而非文本完备性；数量红线（准确率与规则数量负相关）即此标准的推论

**规范体系四层修复框架**：

| 组件 | 故障形态 | 修复手段 | 判定信号 |
|:--|:--|:--|:--|
| 文本 | 歧义/缺失/字面误导（"必存"无条件字面） | 修订文本（条件化） | 按字面执行后出错但规则可达 |
| 触发 | description 未覆盖决策时刻 / 索引截断 | 触发补强（场景词/锚定） | 事后才想起规则（分类先于触发） |
| 流程 | 判据是知识非步骤 | 操作化（N 步清单） | 知道但靠记性 |
| 工具 | 规则不可达（L0） | 工具层修复 | 换正确写法仍失败 |

> 实证：M2 判据审查宽松化 = L1（未加载判据）+ 文本歧义（"必存"字面）双因；反思未加载本技能 = 触发层（分类先于触发，description 补"反思复盘"场景词）

**层选择原则**：优先寻找**可机械化的强制点**（精确匹配/正则/限额/路径检测）→ 工具化（确定性执行）；半机械化（关键词级）→ 流程化 + 事后审计；语义（频率/价值/场景分类）→ 流程清单 + 审计兜底。**规范执行可靠性 = 可机械化程度的函数**——实证：磁盘验证因 memory() substring 匹配可机械化而确定性执行；判据四问因语义不可机械化而概率执行（本会话两次失败）。设计新规范时先问："哪部分可机械化？"——能工具化的优先工具化，只把不可工具化的留给流程。

## 诊断流程（应用失败时）

```
1. 定位失败实例（被质疑的 / 自查发现的）
2. 判别类：换正确写法仍失败 / 工具内部行为？ → L0
           事后才想起规则 / 引用发生在违规之后？ → L1
3. L1 → 按"决策时刻缺什么"选手段：
   缺触发（不知道何时该用）  → 补触发条件：技能 description 纳入"决策时刻"场景
   缺流程（知道但靠记性）    → 判据流程化：写入前强制自检清单（如 memory 四问）
   缺操作（判别表是知识非步骤）→ 操作化：调用前 N 步检查清单
   缺时机（等质疑才执行）    → 主动前置：默认先执行，不等被要求
4. 落盘（技能/记忆）+ git 追溯 + 验证下次生效——知识增量保存：内容级查重已覆盖 → patch 现有，不新建（见 session-knowledge-capture ④）
```

## 预防清单（固化≠执行）

1. **固化不等于执行**——规范写进技能/记忆只解决"存在性"，不解决"加载率"；每次落盘后问：决策时刻会被触发吗？
2. **主动前置**：下结论先分层、写记忆先跑判据、查重先内容级对比——**默认先执行，不等被质疑**；被动响应是应用失败
3. **调查完整性**：引用历史会话/文档前，确认覆盖了**修正记录**（如创建会话中对初始分类的修正）——只引用初始版本会固化错误（本次会话实证）
4. 每轮失败实例记入对应落点的 provenance，形成"失败→修复→复发→再修"的迭代链（**档案留痕，非预防机制**——预防靠折叠进执行点；L1 失败者与档案读者群不相交，见 references/l1-failure-patterns.md）

## 与其他技能的分工（避免重复）

| 技能 | 职责 | 边界 |
|------|------|------|
| `rule-enforcement`（本） | **诊断归因 + 修复手段选择**（为什么没执行） | 元层诊断 |
| `execution-governance` | 行为协议（审批门控/可验证声明/SOUL-USR 边界） | 怎么执行任务 |
| `session-knowledge-capture` | 会话→知识落盘（含主动前置、证据层级原则） | 沉淀侧 |
| `memory-storage-management` | 记忆价值判据四问 + 容量治理 | 记忆域规范 |
| `hermes-agent-skill-authoring` | SKILL.md 写作规范（frontmatter/描述预算/正文形态/内容级查重） | **形式层**——管所有技能怎么写（含本技能）；不归因执行失败 |
| `curator` | 技能生命周期（stale/归档/合并） | 资产维护，**不做行为审计** |

规范体系全貌（分层/职责矩阵/监督关系/落盘链路/触发速查）：见 `references/governance-architecture.md`。

## Pitfalls

1. **把 L0 当 L1 修**——工具层缺陷写规则无效；先判别"换正确写法是否仍失败"
2. **把"事后引用"当"有意识违规"**——引用发生在违规之后 = L1，不是明知故犯
3. **引用初始版本不查修正**——调查历史会话必须滚动覆盖后续纠正消息（作者自身已复发两次，证据链见 frontmatter provenance）；归因时确认引用的是**本体**（skill_view 加载）还是**索引摘要**（见 references/l1-failure-patterns.md）
4. **规范体系无限膨胀**——L1 主战场下，新增规则是低效手段；优先触发补强/流程化/前置
5. **自查 ≠ 等他问**——用户质疑前自己发现并归因，才是主动前置
6. **引用规范前先验证磁盘当前状态**——系统提示中的 USER.md/MEMORY.md 快照**冻结于会话开始**，磁盘文件可能已被用户手动修改/删除（2026-08-05 实证：审计 A2A 会话时引用已删的 R3 日期戳条目，违反"先验证再引用"）。审计历史行为、引用任何规范前：先读磁盘当前内容，不信任会话内快照

## Verification Checklist

- [ ] 失败实例已归因（L0 或 L1，有判别证据）
- [ ] 修复手段与类匹配（L0→工具修复；L1→降低依赖记得）
- [ ] 落盘位置明确 + git 追溯 + 触发条件覆盖决策时刻
- [ ] 调查引用覆盖修正记录（不只初始版本）
- [ ] 未与 execution-governance / memory-storage-management 重复造轮