simplify-code

用途：对已变更的代码做多智能体审查，并落实修复。适用场景为用户要求简化代码、审查改动或清理变更文件时。\n\n流程分为三步。第一步确定审查范围：若提供了具体 diff 命令（如 git diff --cached）就用它；若给出文件列表或目录则直接读取完整文件而非 diff；两者都没有时按当前 git 状态选择合适命令（如 git diff、git diff --cached、git diff HEAD）。若分支是未关闭的 pull request，用 gh pr view --json baseRefName --jq '.baseRefName' 解析基线，执行 git fetch origin <base-branch>，再对 origin/<base-branch>...HEAD 做 diff；无 git 变更时审查对话中最近修改的文件。启动代理前需先列出解析出的文件清单。\n\n第二步并行启动六个审查代理（每条 Agent 调用使用 model: "opus"）：范围审查（应删除的多余抽象、不可达防御代码、重复造轮子、形态不当的测试）；代码复用审查（查找可替代新代码的既有工具与重复功能）；代码质量审查（冗余状态、参数膨胀、复制粘贴、抽象泄漏、字符串类型化、多余包装）；效率审查（重复计算、N+1、算法复杂度、错失并发、热路径负担、TOCTOU 存在性检查、内存与过宽操作）；清晰度与规范审查（项目规范、多余复杂度、命名与嵌套、过度简化、死代码、无谓注释）；实现层次与修复深度审查（共享基础设施上的特例、症状级浅修、放错层次）。各代理将完整发现写入会话暂存目录中的独立文件并返回路径，工作树与 git 索引视为只读，HEAD 保持不变。\n\n第三步汇总发现并逐条修复：同一代码上删除建议优先于重构建议；互相矛盾的补救措施中优先可复现测量的方案，否则采用更窄的方案并说明。依赖源码阅读无法核实的事实前提，需用最低成本检查先行验证，无法验证则跳过并说明。若某发现会改动用户已批准的接口或形态，用 AskUserQuestion 让用户决定，选项包括应用、保持已批准形态、稍后记录（/note-improvement）、寻求第二意见（/consult-codex）。修复落地后，对依赖被改动代码的发现再判一次，最后以表格逐行报告（文件、发现、结果），结果分为已修复、已升级、已跳过；无发现时报告代码已整洁。\n\n限制：依赖具备多智能体调用与工具（TaskList、AskUserQuestion 等）的运行环境；具体安装方式、收费与价格资料未提供。