ce-simplify-code

精简代码，提升清晰度、复用性、质量和效率，并清理没有价值的测试和注释，同时保持行为完全不变。优先编写易读、明确的代码，而非追求代码精简——减少行数不是目标。

模式

在阅读其余内容以确定范围之前，从输入中移除 mode:pipeline 标记和所有 proof-test:<path> 标记。proof-test 路径仅供第 3 步参考，不属于范围；调用方可以传入多个路径。

• Pipeline：存在 mode:pipeline，或当前消息中无人要求执行本次任务时，使用此模式；例如，本次任务是其他技能的一个步骤，或由 Agent 自行启动，例如在任务完成时。只处理当前工作，直接应用修复，无需询问或等待，并向调用方返回第 5 步的摘要。该摘要供调用方留档；绝不可将其粘贴到提交、PR 正文或其他产物中。
• Standalone：用户在当前消息中明确要求执行本次任务时，使用此模式。用户的请求决定范围和重点。除非请求要求直接修复，否则先报告发现的问题，再进行任何编辑。现在阅读 references/standalone-report.md，并在应用任何已报告的问题前再次阅读。

第 1 步：确定范围

按以下顺序确定范围：

1. 用户指定的范围具有最高优先级；不得扩大范围。Standalone 模式下，范围可以是整个仓库、某个区域或某个路径。
2. 否则，如果在 git 仓库中，使用当前分支与其基准分支的差异。如果没有可用的基准分支，则使用已暂存和未暂存的更改（git diff HEAD）。
3. 如果不在 git 仓库中，或没有差异，则使用用户指定的文件，或本次对话中先前编辑过的文件。

Pipeline 模式下，范围由调用方传入；若未传入，则使用分支差异。在该范围内，只清理当前工作新增或修改的测试和注释。

如果以上方法均未得到非空范围，Pipeline 模式应报告“无需精简”并返回。Standalone 模式应按照 references/standalone-report.md 中的说明询问用户要精简什么。

预检。 如果范围内没有实质性的人工作者代码——仅包含文档、生成文件或供应商提供的文件、依赖项或锁文件，或机械性改动——则报告无需精简，并停止，不进行审查。对于混合范围，只保留代码及其测试。此检查依据的是更改类型，而非规模：明确指定的小范围也应执行；任何规模或成本阈值均由调用方设定。

如果平台提供任务跟踪功能，应展示审查、应用和验证的结果，但不要为每位审查者单独创建任务。否则继续执行，不要在聊天中模拟任务列表。

步骤 2：并行启动审查 Agent

在可用时，通过平台的子 Agent 原语（Claude Code 中的 Agent/Task，Codex 中的 spawn_agent）分派通用子 Agent；否则，在线内或按顺序执行审查。对于每位审查者，从此技能目录中读取其提示词资源，并将完整文件内容作为子 Agent 的提示词传入，同时提供已确定的范围（完整差异或文件集）、模式、任何证明测试、用户约束，以及适用于该范围的项目规范（或其文件路径）：

• references/personas/code-reuse-reviewer.md
• references/personas/code-quality-reviewer.md
• references/personas/efficiency-reviewer.md
• 当范围包含测试时，使用 references/personas/test-value-reviewer.md
• 当范围包含注释时，使用 references/personas/comment-reviewer.md

仅针对测试或仅针对注释的独立请求，只运行相应的审查者。

不要凭记忆转述这些评审准则。请读取每个文件并原样传递，否则审查者会失去确保审查过程保持行为不变的规则。

分派前，请阅读 references/reviewer-dispatch.md；其中涵盖完整的执行框架、释放审查 Agent 以及权限模式。

模型选择。 如果当前执行框架支持已知的覆盖设置，请为这些审查者使用平台的均衡型中档模型。在 Claude Code 中，这属于 Sonnet 级别。在 Codex 中，仅当当前分派原语明确提供模型或自定义 Agent 选择器时，才应用此级别；仅靠任务措辞无法选择其他模型。否则，省略覆盖设置并继承父模型——使用父模型顺利完成审查，胜过分派失败。

如果用户或项目的有效指令，或当前提示词，为此子 Agent 指定了模型，则使用该模型，而不是上述默认级别。指定方式可以是子 Agent 的级别、提示词资源名称，或明确指定要分派的子 Agent。若没有此类指令，则此子 Agent 角色配置的模型优先于默认级别。

步骤 3：修复问题

仅在每项审查结果都已完成后继续，无论结果来自子 Agent 还是在线内审查。处于独立模式时，除非请求要求直接修复，否则在此处报告并停止。否则，直接应用有价值的发现；将误报和价值较低的发现记录为跳过，无需询问用户。

必要时可检查已确定范围之外的内容，以评估某项发现，但只能编辑该范围，以及它所需的导入/导出行。对于用户指定的文件或目录范围，这些导入/导出行也必须位于范围内；任何需要在修改边界之外编辑的修复都应跳过。

每项修复都必须保持输出、错误、副作用和顺序不变。若无法确认这一点，则跳过。

绝不要简化或移除安全检查。 保留信任边界验证、防止数据丢失的保护措施、安全检查和无障碍功能。任何会削弱或移除这些内容的发现都应跳过。

保护证明测试。 在流水线模式中，当前工作用来证明变更有效的每项测试都必须保持原样：使用每个 proof-test: 路径；若没有，则使用会话证据中提到的测试。跳过任何会删除、削弱、重命名、移动、合并或重写这些测试，或移除、重命名这些测试所调用的仅供测试使用的代码的发现。对这些测试所覆盖的生产代码进行保持行为不变的修改仍可应用。如果无法确定哪些测试属于此类，则不要删除或重写当前工作新增或修改的任何测试。

遵守调用方传入的结构固定项。 通过结构固定约束传入的计划路径仅作上下文，不属于范围。保留其 session-settled:「关键技术决策」，包括有意的重复或分离。

第 4 步：验证行为是否得到保留

运行整个项目的类型检查和 lint。根据影响范围运行匹配的测试：局部更改运行指定范围的测试，共享或影响范围广的更改运行更广泛的测试；如果测试运行器无法指定范围，则运行完整测试套件。

报告失败时，注明检查名称和相关输出。修复由简化导致的失败，或撤销相关更改。绝不通过削弱或删除测试来让检查通过。只有在确认测试价值后才能删除测试；此类确认中提及的其他测试之后仍必须通过。

如果未配置测试套件、lint 或类型检查，请在摘要中明确说明；不要悄悄跳过验证。

第 5 步：总结

总结原本已完善的部分和改进之处。按复用、质量、效率、测试和注释分别报告应用的更改数量；报告跳过数量、检查结果，以及因约束无法编码而保留的任何注释。如果没有任何更改，请明确说明。不要以删除的净行数作为成功指标。在流水线模式下，此摘要会结束此技能，而非结束本轮对话：调用方的下一步将在摘要之后执行。