ce-simplify-code

在严格保证原有行为不变的前提下，对最近修改的代码进行简化，提升其可读性、复用度、代码质量与运行效率。优先追求清晰易读、意图明确的代码，而不是盲目追求极致精简 —— 代码行数越少绝不等于越好。

Setup

在本次调用的开头、派发任何子 Agent 之前执行一次以下代码，并遵循其输出的指令 —— 除非其中的某条指令与本 Skill 自身关于询问用户的规则相冲突（无论该规则仅适用于非交互模式还是适用于所有模式，这种情况下以本 Skill 的规则为准，不发起阻塞式提问）。请严格按原样将代码块作为独立命令运行：不要通过管道过滤（不要使用 head、tail 或 grep），不要截断其输出，也不要将其与其他命令打包成批处理。其输出以 === skill context 头部开头，并以 CE_CONTEXT_END 结尾；如果你只收到了其中一行而没有另一行，说明输出被截断了 —— 请按原样重新运行一次该代码块。这种恢复是唯一允许的重试行为：除此之外，切勿在同一次调用中重复运行；后续调用此 Skill 或其他 Skill 时会自动运行各自的脚本。如果没有可用的 Node 运行时，Skill 将按正常流程继续执行。

SKILL_DIR="<absolute path of the directory containing the SKILL.md you just read>";
NODE="$(for c in node nodejs; do command -v "$c" >/dev/null 2>&1 && "$c" -e '' >/dev/null 2>&1 && { echo "$c"; break; }; done)";
if [ -n "$NODE" ]; then
"$NODE" "$SKILL_DIR/scripts/context.mjs" || echo "context script failed; continue with the skill's normal behavior";
else
echo "no Node runtime; continue with the skill's normal behavior";
fi

Step 1: Identify scope

按以下优先级确定要简化的代码范围：

1. 如果用户明确指定了范围（如某个文件、目录、“我刚才写的函数”、“今天早上的修改”），直接使用该范围。将用户指定的范围视为权威依据 —— 切勿擅自扩大范围。
2. 否则，在 Git 仓库中，默认对比当前分支与基准分支之间的 diff（例如 git diff origin/main... 或对比已配置的上游分支）。这涵盖了最常见的场景：“提交 PR 前简化我在这个特性分支上新增的所有代码”。如果该分支没有上游或基准引用，则退而求其次使用已暂存 + 未暂存的改动（git diff HEAD）。
3. 在 Git 仓库之外或无法获取 diff 时，审查用户提及的或本次对话早期编辑过的最新修改文件。

如果上述方法均未能产生非空的范围，请暂停并主动询问用户需要简化什么，而不是凭空猜测。请使用当前平台的阻塞式提问工具：Claude Code 中的 AskUserQuestion（如果未加载 schema，先调用 ToolSearch 并带上 select:AskUserQuestion）、Codex 中的 request_user_input、Antigravity CLI（agy）中的 ask_question、Pi 中的 ask_user（需要 pi-ask-user 扩展）。只有当宿主环境中不存在阻塞式工具或调用报错（例如 Codex 编辑模式）时，才退而求其次在对话中使用带序号的选项 —— 切勿仅因需要加载 schema 就放弃调用。绝对不要默默跳过提问。

预检 —— 在派发审查员之前跳过无实质收益的范围。 三位审查员的任务是排查代码中的复用性、质量和效率问题。如果确定的范围中不包含任何实质性的手写代码 —— 例如仅包含文档/Markdown 改动、自动生成的代码、第三方依赖库（vendored）、依赖包/锁文件，或者纯机械化的变动（格式化、lint 自动修复、批量重命名）—— 请在此终止，并附上一句提示说明“无需简化”，且不要派发审查员。如果是包含真实代码与上述无收益变动的混合 diff，请将范围缩小至代码文件后继续。此预检仅针对改动的类型进行把关，绝不针对改动的行数或数量：用户明确指定的范围具有最高优先级，即使改动极小也会正常运行。（已经对改动规模进行把关的调用方（如 ce-work、lfg）以及任何预置的“自动运行”指令自行负责规模/成本策略；本预检仅作为“无代码改动”的安全网。）

当预检通过后，如果当前平台支持任务追踪功能（task-tracking），请用其向用户展示基于后续工作流提炼的简短视图。请追踪实质性的审查、应用与验证结果，而不是为每个审查员单独创建任务或机械照搬每个步骤；仅在条件触发时才添加条件任务。如果平台不支持任务追踪，正常继续即可，无需在聊天中假装输出任务列表。

Step 2: Launch 3 review agents in parallel

如果平台支持子 Agent 原语（如 Claude Code 中的 Agent/Task，Codex 中的 spawn_agent），请并行派发 3 个通用子 Agent —— 代码复用（code-reuse）、代码质量（code-quality）和运行效率（efficiency）审查员；否则内联或串行运行这些审查。对于每个审查员，从本 Skill 目录读取其 Prompt 资源，并将完整的文本内容与确定的范围（完整的 diff 或文件集合）一并作为 Prompt 传给子 Agent，以便其获取完整上下文：

• references/personas/code-reuse-reviewer.md —— 已有工具函数、重复功能、重新实现的标准库/运行时原语。
• references/personas/code-quality-reviewer.md —— 冗余状态、参数膨胀、复制粘贴、抽象泄漏、弱类型（stringly-typed）代码、死代码、过度嵌套，以及防止“过度简化”的平衡把关。
• references/personas/efficiency-reviewer.md —— 不必要的计算/操作、遗漏的并发处理、热点路径代码臃肿、无意义的更新、内存泄漏。

切勿凭借记忆凭空转述这些审查标准 —— 必须读取每个文件并原样完整传递，否则审查员可能会遗漏确保“保持行为不变”的核心把关规则。

限流派发（Bounded dispatch）。 将 3 个审查员放入队列，并且只启动宿主环境允许并发运行的数量；如果遇到并发/活跃 Agent 上限错误，请将其视为反压机制（让审查员留在队列中，等空出名额后再试），而不是审查员运行失败。

模型选择。 当当前宿主环境支持显式覆盖模型时，为这些审查员选择平台中均衡的中端模型（mid-tier model）。在 Claude Code 中即为 Sonnet 级别。在 Codex 中，仅当当前派发原语暴露了显式的模型或自定义 Agent 选择器时才应用该级别；单纯的任务措辞不会触发模型切换。否则省去覆盖配置，直接继承父级模型 —— 在父级模型上正常运行远胜于因模型设置错误导致派发失败。

权限模式。 在派发调用中省去 mode 参数，以便应用用户预先配置的权限设置。

Step 3: Fix issues

等待所有 3 个 Agent 执行完毕。汇总它们的审查结论并直接修复各个问题。如果某个结论属于误报或没有修改价值，记录一下即可继续，无需与审查结论争论或向用户提问，直接跳过即可。

在应用每次修复之前，请确保其严格保持原有行为：对于任何输入输出保持一致，错误处理行为一致，副作用与执行顺序一致。如果某个修复无法通过此检验，请直接跳过 —— 步骤 4 中的自动化检查无法覆盖所有行为细节。

绝不要简化掉安全防护检查。 信任边界处的输入校验、防止数据丢失的错误处理、安全检查（鉴权、转义、净化）以及无障碍支持（accessibility），都不是可以随意删减的样板代码 —— 即使审查结论认为它们冗余或可被内联，也必须完整保留。删除了这些防护的代码不是更简洁，而是未完成。如果建议的简化会削弱或移除这些检查，请直接跳过。

遵守调用方传入的架构锚定约束（structure pins）。 当调用方传入带有架构锚定约束（structure-pin）的 Plan 路径时，该 Plan 路径仅作为上下文参考，绝不是简化的目标范围；该 Plan 中带有 session-settled: 标记的“关键技术决策”属于简化过程必须遵守的架构约束 —— 故意保留的重复文件必须保持重复，故意拆分的独立实现必须保持独立 —— 即使从代码层面看合并是显而易见的简化方案。保持原有行为本身就约束着每次修复，而此规则将其延伸至既定的架构设计。

Step 4: Verify behavior is preserved

本 Skill 的核心前提是简化过程必须严格保持原有功能。应用修复后：

在全项目范围内运行类型检查（typecheck）和 lint。 它们通常运行很快，且能捕捉最常见的简化回归问题 —— 比如引用损坏、未使用的导出、类型收窄失效，以及其他模块仍引用的废弃代码。

运行测试：

• 运行针对修改路径的测试。CI 会在提交 PR 时运行全量测试 —— 本地检查的目标是快速反馈，而非最终保障。测试范围应与影响半径相匹配；为了 3 行代码的简化去跑 20 分钟的全量测试并不划算。
• 当改动具有明显的全局影响时，扩大测试范围 —— 例如重写了一个被广泛引用的工具函数，或者代码质量审查员的合并/去重修复修改了共享代码。这是基于波及风险的主观判断，而非机械硬套的规则。
• 如果测试运行器不支持按范围过滤，则运行全量测试套件。

清楚地呈现任何失败信息，包含失败的检查名称及相关输出。切勿为了让检查通过而放宽断言、削弱类型签名或跳过测试 —— 这违背了“保持功能不变”的承诺。要么修复简化引发的潜在破坏，要么还原导致回归的具体修改。

如果项目未配置测试套件、lint 或类型检查，请在总结中明确说明，切勿默默跳过验证环节。

Step 5: Summarize

简要总结哪些方面表现良好，哪些方面得到了改进和修复，包括运行了哪些检查以及相应的结果。如果没有需要处理的问题，确认代码无需任何修改。

按维度量化影响。 汇报实际应用的修复项，而不是单纯统计代码行数：按审查维度（复用性、代码质量、运行效率）统计已应用的修复数量，说明有多少问题因误报或无需处理而被跳过，以及行为保持一致性的验证结果（运行的检查项及结果）。例如：“已应用 6 项修复 —— 复用性 2 项，代码质量 3 项，运行效率 1 项；跳过 2 项误报；类型检查与 lint 通过，11 个局部测试通过。” 切勿将“净减少的代码行数”作为标题重点或当作主要成绩 —— 许多关于清晰度、安全性与效率的修复往往会保持甚至增加代码行数。衡量标准在于改进了什么以及行为是否稳定，而不是代码精简了多少。