no-comments

没有注释

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

优先听取 Comment Sicko 的全新视角。

范围

使用调用方提供的文件或差异。否则，使用当前差异与合并基点（默认分支为 git merge-base HEAD origin/HEAD，若不存在则使用 main 或 master）进行对比，并包含工作树。如果没有 Git，则使用本次会话中更改的文件。

步骤

1. 启动一个名为 Comment Sicko 的 review 子 Agent。使用 ~/.config/ox/models.md 中的 review 行：将其中的模型和推理强度传给子 Agent 工具。如果该行是 inherit、缺失，或者文件中的 # harness 行指定了不同的 harness，则省略两者，让子 Agent 使用你的模型；如果文件不存在，还要建议用户运行 /setup-ox models。其任务说明为 COMMENT-SICKO.md 的原文，后接范围。不要复述其中的规则。如果 harness 没有子 Agent 工具，说明这一点，并以该文件作为任务说明自行进行检查。
2. 检查其报告和差异。拒绝应用代码修改、超出范围的修改、受异常保护的删除、对 MUST KILL 理由的不实陈述，以及将保留的有意代码判为问题的标记。针对我方代码意外之处的标记仍须具有可操作性。不要恢复这些注释。只有在有证据证明内容与我们无法更改的事项有关时，才保留注释。审查遗漏的、限定作用域的抑制项（---@diagnostic disable、eslint-disable、@ts-ignore、@ts-expect-error）。与正确性或安全性有关的抑制项仍须作为可操作的 MUST KILL 处理。只有存在明确例外且有范围内的证据时，才恢复删除的注释。接受较弱的 IMPORTANT 或 do not remove 类 MUST KILL 标记或保留项之前，先自行追踪其符号：检查调用方，并使用 git log -L 或 git blame 查明注释出现的时间和原因。若删除理由含糊，不要恢复注释。若保留理由被证伪或仍含糊，则删除该注释。若要在全新的子 Agent 中重跑一份被拒绝的报告，请指出失败原因。若第二次仍被拒绝，则记录为待解决事项，并使 no-comments 检查失败。
3. 直接删除无效路径、移除参数或改用真实 API，修复已接受的简单标记。如果任何修复需要设计方案，则针对已接受项及其周边代码只起草一次方案：说明数据结构和需要修改的函数。到此为止。第 4 步再实施。
4. 在范围内实施最小化的根因修复。移除所有点名的变通方案。如果根因超出范围，则提交最小范围内的修复，并将其余部分报告为待解决事项。Fix Root Causes 和 Redesign from First Principles 原则（调用 Skill 工具并传入 principles）仅用于指导意图。它们均不授权扩大范围，也不允许修复范围之外的问题。绝不要增加针对症状的保护措施。
5. 约束类注释如果写着 do not remove、do not change wording 或 talk to X before changing，则保留那些与我们无法更改的事项有关的注释。其余约束用范围内成本最低的类型、运行时检查、测试或 CI lint 来表达，然后删除注释。如果范围内无法表达，则删除注释，报告该约束仍未解决，并概述范围外所需的工作。
6. 报告删除数量、恢复的注释、重跑情况、方案、修复、编码后的约束、未强制执行的约束，以及其他待解决事项。