no-comments

无评论

以粗体或反引号标出的技能名称，或以 /<name> 形式运行的技能，是此技能目录旁的 ../<name>/SKILL.md 文件；未带前缀的原则名称对应 ../principle-<name>/SKILL.md。阅读相应文件并遵循其中要求。大多数 pstack 技能仅供用户使用，因此你的技能工具无法加载它们。每次调用 delegate_task 都遵循 ../poteto-mode/SKILL.md 的 Subagents 部分中的默认设置。

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

听从 Comment Sicko 的全新视角。

范围

使用调用方提供的文件或差异。否则，使用当前与基准分支（默认为 main）之间的差异，包括工作树中的内容。

步骤

1. 使用 ~/.config/pstack/pstack-models.md 中的 judgment and prose 模型（若文件或行缺失，则使用父模型），启动一个标题为 Comment Sicko 的 delegate_task 子任务。其任务说明以逐字粘贴的 references/comment-sicko.md 开头，随后提供 how 和 why 的 SKILL.md 文件绝对路径，并附上“Before you run /how or /why, read that SKILL.md in full and follow it”，最后说明范围。根据 poteto-mode 技能的 Subagents 部分，为每个子代理选择适合任务的推理级别以及快速或标准速度。不要复述其规则。
2. 检查其报告和差异。拒绝应用代码编辑、超出范围的改动、受例外保护的删除、错误陈述 MUST KILL 理由的内容，以及将保留的有意代码错误标记为有问题的旗标。对我们代码中意外之处的旗标，应调整为可执行的内容。不要还原这些注释。只有能证明注释涉及无法更改的内容，才能保留。审查遗漏的、范围内的 lint 和 TypeScript 抑制项。正确性或安全性抑制项仍应作为可执行的 MUST KILL。只有在具备精确例外和范围内证据时才还原删除的注释。对于内容单薄的 IMPORTANT 或 do not remove 类 MUST KILL 或保留项，先对其符号运行 /how 或 /why。如果 MUST KILL 有歧义，不要还原。如果保留项被证伪或仍有歧义，则删除。撤销并在新的 delegate_task 中重新运行一次被拒绝的报告，并指出失败原因。若第二次仍被拒绝，则将其报告为未解决项，并使 /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 草图、修复、提出的编码方案、已编码的约束、未强制执行的约束及其他未解决事项。