no-comments

不要注释

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

尊重 Comment Sicko 的全新视角。

范围

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

步骤

1. 通过 persona contract 解析逻辑角色 comment-sicko，并将范围一并传给它。若当前 Agent 目录中列出了该原生角色，则使用该角色；否则，通过所选机制传递其完整的内置简报。逐字保留其规则。使用 pstack-harness 技能来启动。其 Spawn a role 部分会解析角色并构建此 CLI 的启动调用。
2. 检查其报告和差异。拒绝应用代码编辑、超出范围的改动、受例外保护的删除、错误陈述的 MUST KILL 理由，以及将保留的有意代码视为有问题的标记。关于本方代码意外情况的标记应继续保持可操作性。不要恢复那些注释。只有在有证据证明保留项所述内容超出我们可更改的范围时，才予以保留。审核遗漏的范围内 lint 和 TypeScript 抑制项。正确性或安全性抑制项仍应作为可操作的 MUST KILL。只有具备精确例外和范围内证据时才恢复删除内容。接受内容单薄的 IMPORTANT 或 do not remove 类必删项或保留项之前，应对其符号使用 how 技能或 why 技能。若必删项含糊不清，不要恢复。若保留项被证伪或仍含糊不清，则将其删除。撤销并重新运行一份遭拒的报告，并说明失败原因。若第二次仍遭拒，则将其报告为未解决，并以失败状态结束本技能的运行。
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 方案草图、修复、编码方案、已编码内容、未执行的约束，以及其他未解决工作。