单 Skill 自我审计协议
定位
不是跨 skill 合并，是针对单个 skill 内部的优化后自洁。严格两阶段，顺序不可颠倒：
- 优化阶段：按优化要求执行优化（只做优化，不掺审计）
- 审计阶段：优化完成后，以优化后的功能为基准，合并内部重复段落/规则/步骤，但优化成果一个都不能丢
两阶段铁律（违反即失败）
优化阶段（先）
- 按优化要求来：用户要求优化什么就优化什么（改逻辑/加能力/改表达），不做内部整理，专注优化本身。
- 优化前备份：
cp SKILL.md SKILL.md.bak，保证可回滚。
审计阶段（后，优化完成后才进入）
- 以优化后功能为基准：合并同类项时，保留的是"优化后的功能集"，不是优化前的。优化新增的能力、修改的逻辑、调整的表达，一律保留。
- 不删功能：审计只做"合并重复/压缩冗余/整理结构"，绝不允许移除任何功能点、能力、触发场景、规则条目。除非用户明确要求删除某功能。
- 功能清单比对：优化完成后提取该 skill 的功能清单（它提供哪些能力/触发词/规则），审计合并后逐项核对，任何一项缺失（含优化新增的）即审计失败，必须恢复。
- 引用式调用：审计过程中引用其他 skill 的能力时，遵守 twu-skill-contract 的引用式调用（不抄命令，执行时重读）。
审计流程（优化完成后执行）
Step 1 确认优化完成
确认优化已按用户要求完成，优化成果已生效。
Step 2 提取功能清单（优化后的基准）
读取优化后的 SKILL.md，列出当前（含优化成果）的功能清单：
- 能力点（每个 section/模块提供的功能，含优化新增的）
- 触发词（frontmatter description 里的所有触发场景，含优化后调整的）
- 规则条目（每条铁律/约束，含优化后修改的）
- 外部依赖（引用了哪些其他 skill / 脚本）
Step 3 内部同类项扫描
在同一个 skill 内部查找（此时以优化后内容为准）：
- 重复段落：语义相同的规则/说明出现多次
- 冗余步骤：流程里重复的动作
- 可合并的规则条目：多条约束能合并成一条更清晰的
- 重复触发词：description 里同一场景写了多遍
Step 4 合并（严格保功能）
对 Step 3 找到的同类项做合并：
- 多条重复规则 → 合并为一条，但每条原有信息都保留在合并体中（不丢任何约束，含优化新增的）
- 重复段落 → 收敛到一处，其余引用之
- 冗余步骤 → 精简描述，但每个步骤的功能动作保留
- 合并时使用"功能等价改写"：新文本能覆盖旧文本（含优化后）的全部能力
Step 5 功能清单核对
用 Step 2 的功能清单逐项比对审计合并后的 skill：
- 每个能力点仍在？（含优化新增的）
- 每个触发词仍能被触发？
- 每条规则仍在（可能换了个说法）？
- 外部依赖仍有效？
任一缺失（含优化成果） = 审计失败，回滚到优化完成时的状态，重新合并。
Step 6 记录变更
在 skill 的 SKILL.md 末尾或项目日志记录：
- 优化了什么（优化阶段成果）
- 合并了哪些同类项（审计阶段动作）
- 功能保留确认（逐项列出未丢失，含优化新增项）
合并判据
| 情况 | 动作 |
|---|---|
| 同一功能点出现 ≥2 次 | 合并，保留全部信息（含优化后版本） |
| 规则语义相同但措辞不同 | 统一为一条，涵盖所有约束 |
| 流程步骤重复 | 精简为一次，功能不变 |
| 触发词重复 | 去重，保留所有场景 |
| 不同功能（即使相邻） | 不合并，保持独立 |
验收标准
- 优化成果完整保留：优化新增的能力/逻辑/表达全部在，一个不丢
- 合并只针对内部重复，合并后功能清单与优化后的基准一致（逐项可核）
- 内部无语义重复段落
- 无任何功能被删除，除非用户明确要求
- 变更已记录，可回滚
与 twu-self-evolving 的关系
本 skill 是"优化后即时自洁"，由 twu-self-evolving（进化引擎）在每次优化完成后引用执行；本 skill 只负责单 skill 内部审计，不负责跨 skill 合并。
