no-comments

不要注释

启动 Comment Sicko。处理已接受的发现。

听从 Comment Sicko 的全新视角。

范围

使用调用方的文件或差异。否则，使用当前与基准分支的差异，默认是 main，并包括工作树。

步骤

1. 启动 Task，并设置 subagent_type: "Comment Sicko"。传入范围。不要复述其规则。
2. 检查其报告和差异。拒绝应用代码编辑、超出范围的修改、受异常保护的删除、错误陈述的 MUST KILL 理由，以及将保留的有意代码视为有问题的标记。针对我们代码中意外情况的标记仍需处理。不要恢复那些注释。只有在有证据证明注释涉及我们无法更改的内容时，才保留。审查遗漏的范围内 lint 和 TypeScript 抑制项。正确性或安全性抑制项仍应作为可执行的 MUST KILL 处理。只有在存在精确例外和范围内证据时，才恢复删除内容。接受依据不足的 IMPORTANT 或 do not remove 删除项或保留项之前，先对其符号运行 /how 或 /why。如果删除项含糊不清，不要恢复。如果保留项被证伪或仍有歧义，就删除它。撤销并重跑一份被拒绝的报告，并注明失败原因。第二次仍拒绝时，将其报告为未解决，并让 /no-comments 失败。
3. 直接修复已接受的简单标记：删除无效路径、移除参数，或使用实际 API。如果任何修复需要调整结构，则针对已接受的集合及周边代码运行一次 /architect。到草图阶段即停止。结构由 Architect 设计。第 4 步负责实现。
4. 在范围内实施最小的根因修复。移除所有点名的变通方案。如果根因超出范围，则提交范围内最小的修复，并将其余部分报告为未解决。principle-fix-root-causes 和 principle-redesign-from-first-principles 技能仅用于指导意图。两者都不允许扩大边界或修复范围之外的实例。绝不要额外添加症状防护。
5. 约束类注释会写明 do not remove、do not change wording 或 talk to X before changing。保留那些涉及我们无法更改内容的注释。提供成本最低的范围内类型、运行时、测试或 CI lint 方案。等待交互式批准。无人值守和评估场景需要调用方事先批准。如果获批，先编码约束，再删除注释。否则删除注释，将该约束报告为未解决，并概述范围外工作。
6. 报告删除数量、恢复的注释、重跑情况、Architect 草图、修复、编码方案、已编码内容、未执行的约束，以及其他未解决工作。