sip

尝一口自己做的菜：每当你完成某项创作，就在端上桌之前，用这个代码库提供的技能检查成果。

目标

文档里深埋的一句提醒（“记得验证”）无法确保在全新会话中可靠触发。sip 将递归式自我改进循环变成一种触发式习惯：每次创建或修改内容后，立即用我们自己的技能检查成果——既做常规检查，也做真实性检查——这样质量就不会取决于作者在当前会话中的主观判断。

工作流

1. 识别触发时机：你刚创建或修改了一项产物或技能，正准备宣布完成、提交或交接。
2. 冷读检查——对产物运行 shower（检查新鲜视角下的理解效果／交接质量）。
3. 验证真实性——如果产物声称某项基于现实的事实，就运行 factchk；如果产物定义了评估、指标或实验，就运行 mandela。两者都不涉及则跳过。
4. 检查一致性——在整个代码库中以审计模式运行 ssotize，查找此次改动重复或矛盾之处；只有获得批准后，才执行其整合计划。
5. 清除工具依赖——仅当产物声称具有可移植性、工具中立性、跨技术栈的持久性或可供多个 Agent 复用时，才运行 detool。如果产物是来源记录、操作说明、面向特定工具的运行手册，或没有声称具备可移植性，则跳过。
6. 整理——对修改过的文档运行 re0，让成果读起来像干净的 v0，而不是在草稿上打的补丁。
7. 在此处应用检查结果，然后再交付。

规则

• 在你产出内容后立即触发——此时偏见最强，检查成本最低。
• 使用这些技能，不要重新实现它们——shower 检查清晰度，factchk/mandela 检查真实性，ssotize 检查 SSOT，detool 检查可移植性声明，re0 负责清理。sip 负责协调，并将检查结果反馈给作者会话以便修正；具体工作由这些技能完成。
• 明显不适用的检查，或未安装相应技能时，跳过即可——只运行现有技能。只有存在事实声明或评估时，才运行 factchk/mandela；只有产物声称具备可移植性、工具中立性、跨技术栈的持久性或可供多个 Agent 复用时，才运行 detool；一句话的措辞调整可能只需检查一致性。说明跳过了哪些检查以及原因。
• 检查到产物为止——sip 绝不操作 git 或创建提交。
• 只串联由模型调用的技能；由用户调用的技能（标记为 disable-model-invocation）应由用户主动触发，因此 sip 不得调用此类技能。

验证

完成前：

1. 确实使用相关技能检查了改动，而不是只凭目测。
2. 已应用检查结果（或说明理由，并审慎决定暂缓处理）。
3. 产物确实因检查而有所改动（存在差异），或者已说明跳过每项技能的理由。