需要清理可疑注释并只处理经审核接受的发现时，用…

当你要基于调用方文件或当前 diff 清理可疑注释、失效 lint/TS 抑制与约束注释，并只对经审核接受的发现做修复时使用。

适用场景

解决思路

1. 确定范围：使用调用方的文件或 diff；否则使用相对 base branch（默认 main）的当前 diff，并包含工作区改动。
2. 用 Task 启动 `subagent_type: "Comment Sicko"`，传入范围。不要复述其规则。
3. 遵从 Comment Sicko 的新鲜视角。
4. 检查 Comment Sicko 的报告和 diff。
5. 拒绝应用代码编辑、范围逃逸、受异常保护的删除、错误陈述的 MUST KILL 理由，以及把保留的有意代码当作有罪的标记。
6. 对“我们代码”中意外之处的标记进行重塑，使其保持可执行。
7. 不要恢复那些被拒绝的注释。
8. 一个 keep 只有在有证据证明它涉及我们无法改变的事情时才能保留。
9. 审计范围内被遗漏的 lint 和 TypeScript 抑制。
10. 正确性或安全性抑制保持为可执行的 MUST KILL。
11. 只有具备精确例外和范围证明时才恢复删除。
12. 在接受单薄的 IMPORTANT 或 do not remove 的 kill 或 keep 之前，对其符号运行 /how 或 /why。
13. 如果 kill 有歧义，不要恢复。
14. 如果 keep 被驳倒或仍有歧义，删除它。
15. 对一个被拒绝的报告进行回退并重跑，并指明失败原因。
16. 拒绝第二个报告，将其报告为 open，并让 /no-comments 失败。
17. 直接修复琐碎的已接受标记：删除死路径、去掉参数或使用真实 API。
18. 如果任一修复需要形态设计，对已接受集合及周边代码运行一次 /architect。停在草图阶段。Architect 负责形态，第 4 步负责实现。
19. 在范围内实现最小的根因修复。移除所有已命名 workaround。
20. 如果根因超出范围，落地最小的范围内修复，并将其余部分报告为 open。
21. principle-fix-root-causes 和 principle-redesign-from-first-principles 技能只指导意图；两者都不授权扩大围栏或修复围栏外实例。
22. 绝不要加装症状守卫。
23. 约束注释会说 do not remove、do not change wording 或 talk to X before changing；保留关于我们无法改变之事的 keep。
24. 提供最便宜的范围内类型、运行时、测试或 CI lint 编码方案。
25. 等待交互式批准。无人值守和 eval 需要调用方预先批准。
26. 如果批准，先编码再删除；否则删除，将约束报告为 open，并草拟范围外工作。
27. 报告删除数量、恢复的注释、重跑、architect 草图、修复、编码提议、编码、未强制约束和其他开放工作。

适用边界 · 注意事项

• 缺少 Comment Sicko 子代理，或缺少 /how、/why、/architect、/no-comments 等配套命令/流程时不要使用。
• 根因在范围外时不要扩大范围修复，也不要修复围栏外实例或加装症状守卫。
• 没有精确例外和范围证明时不要恢复被删除的注释；不要恢复被拒绝报告中的注释。