刚创建或修改产物/技能后，用现有技能自动自检以保证交付质量

在刚创建或修改产物或技能、准备宣布完成/提交/交接前，触发用现有技能对结果做冷读、真实性、一致性、可移植性和整洁度自检。

适用场景

解决思路

1. 把递归自我改进循环固定为触发习惯：任何创建或更改后立即对结果运行自己的技能，既做整洁性检查也做真实性检查，避免质量依赖作者在会话内的有偏判断。
2. 在自己的输出刚产生后立即触发检查；此时偏见最高、检查成本最低。
3. 识别触发：刚创建或更改产物或技能，并准备宣布完成、提交或交接时，启动自检流程。
4. 冷读产物：对产物运行 `shower`，做新鲜视角理解/交接检查。
5. 验证真实性：如果产物含有有现实依据的断言，运行 `factchk`；如果定义评估、指标或实验，运行 `mandela`；两者都没有则跳过。
6. 检查一致性：在整个仓库中以 audit mode（审计模式）运行 `ssotize`，检查本次变更重复或矛盾的内容；只有获得批准后才执行其 consolidation plan（整合计划）。
7. 检查可移植性声明：仅当产物声称可移植性、工具中立性、与技术栈无关的持久性或跨 agent 复用时，运行 `detool`；若产物是来源说明（provenance）、操作笔记（operational notes）、面向特定工具的 runbook（tool-targeted runbook）或未声称可移植性，则跳过。
8. 整理：对变更过的文档运行 `re0`，让结果读起来像干净的 v0，而不是在草稿上打补丁。
9. 在作者会话中应用这些发现，然后交付结果。
10. 使用现有技能，不要重新实现它们：`shower` 负责清晰度，`factchk`/`mandela` 负责真实性，`ssotize` 负责 SSOT，`detool` 负责可移植性声明，`re0` 负责清理；`sip` 负责编排并把发现路由回作者会话修复。
11. 跳过明显不适用或技能未安装的检查：只运行存在的技能，并说明跳过了什么及原因。`factchk`/`mandela` 仅当存在断言或评估时触发；`detool` 仅当产物声称可移植性、工具中立性、与技术栈无关的持久性或跨 agent 复用时触发；一行文字调整可能只需要一致性检查。
12. 停在产物层面：`sip` 绝不触碰 git 或进行提交。
13. 只串联模型可调用的技能；用户调用的技能（标记为 `disable-model-invocation`）应由人类故意触发，`sip` 不得调用。
14. 完成前验证：变更确实通过相关技能运行，而不是仅凭肉眼检查。
15. 完成前验证：发现已应用到产物，或有意识地推迟并说明原因。
16. 完成前验证：产物因检查实际发生了变化（存在 diff），或每个跳过的技能都有说明原因。

适用边界 · 注意事项

• 当相关技能未安装，或检查明显不适用时，不要强行运行；只运行存在的技能，并说明跳过项及原因。
• 产物没有有现实依据的断言或评估/指标/实验时，不要运行 `factchk`/`mandela`；产物不声称可移植性、工具中立性、与技术栈无关的持久性或跨 agent 复用，或只是来源说明、操作笔记、面向特定工具的 runbook 时，不要运行 `detool`。
• 不要调用标记 `disable-model-invocation` 的用户调用技能；不要由 `sip` 执行 git 操作或提交；一行文字调整可能只需一致性检查。