no-comments

无注释

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

尊重 Comment Sicko 的全新视角。

范围

使用调用方提供的文件或差异。否则，使用当前相对于基准分支（默认为 main）的差异，包括工作区中的更改。

步骤

1. 使用 subagent_type: "comment-sicko" 启动 Task。向其传递范围。根据 poteto-mode 技能的 Subagents 部分，为每个子代理选择适合任务的推理级别和快速或标准速度。不要复述其规则。如果你的运行环境没有将 comment-sicko 注册为子代理（除安装了 pstack 插件的 Cursor 以外的任何运行环境），则改为启动通用子代理：在 Claude Code 中使用 Agent（subagent_type: general-purpose），在 OpenCode 中使用 task（subagent_type: general），在 Codex 中使用 spawn_agent。其提示词为 references/comment-sicko.md 的原文，后接范围。如果你的运行环境没有子代理工具（例如没有扩展的 Pi），则在重新检查范围时自行运行该提示词。
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 草图、修复、编码提议、已编码内容、未强制执行的约束，以及其他未解决工作。