| name | ac-review |
| description | 代码审查:无参数时自动审查 git diff,支持按 git revision 审查指定提交,并在确认整改范围后生成执行计划。 |
| disable-model-invocation | true |
Review - 审查归档 + 整改计划生成
由 Claude 在当前会话内完成代码审查。无参数时自动审查当前 git 变更,也可传入 git revision 审查指定提交;审查过程中由主线程统筹,并通过 subagents 并行执行子任务。主线程先汇总结果并写入 .claude/review/<功能名>.md Markdown 审查报告;当用户确认“哪些要改、哪些不改”后,再生成并写入 .claude/plan/review-<功能名>.md Markdown 实施计划。
使用方法
/ac-review [代码|描述|git修订号]
- 无参数:自动审查
git diff HEAD
- 参数为 git 修订号:审查该次提交的修改
- 其他参数:审查指定代码或描述
角色分工
| 角色 | 职责 |
|---|
| Claude(主线程) | 获取待审查内容、拆分子任务、汇总结果、写入 .claude/review/*.md、询问整改范围、生成 .claude/plan/review-*.md、输出最终提示 |
| subagents | 并行检索上下文、执行分项审查、返回问题列表 |
执行约束
工作目录:
{{WORKDIR}}:使用当前工作目录的绝对路径作为审查根目录
- 如果用户通过
/add-dir 添加了多个工作区,先用 Glob/Grep 确定任务相关的工作区
- 如果无法确定,用
AskUserQuestion 询问用户选择目标工作区
重要:
- 必须由 Claude 主线程发起审查,并使用
Agent 工具启动 subagents 执行子任务
- 若多个独立子任务可并行,必须在同一轮并行启动多个 subagents
- 已委托给 subagents 的搜索、阅读或审查内容,主线程不要重复执行
- subagents 只做检索与审查,不做代码修改,不直接向用户输出最终结论
- 所有审查意见必须由主线程统一去重、分级,并整理为审查报告
- 审查阶段不修改产品代码;唯一允许的写操作是生成
.claude/review/*.md 与 .claude/plan/review-*.md Markdown 文件
- 必须先生成审查报告,再询问用户整改范围;未经用户确认,不得直接生成执行计划
执行工作流
🔍 阶段 1:获取待审查代码
[模式:研究]
无参数时:执行 git diff HEAD 和 git status --short
参数为 git 修订号时:执行 git show --stat --patch <revision> 获取该次提交的修改
其他参数时:使用指定的代码/描述
调用 {{MCP_SEARCH_TOOL}} 获取相关上下文。
🧩 阶段 2:拆分审查子任务
[模式:规划]
主线程先基于变更范围拆分子任务,再并行发起 subagents。默认至少拆成以下两个方向:
- 正确性与回归风险审查
- 可维护性与集成风险审查
- 检查命名与职责、重复逻辑、测试缺口、跨模块/接口一致性
若变更范围较大,可继续按文件组、模块或专题新增子任务,但必须保持“可并行、职责清晰、结果可汇总”。
🔬 阶段 3:并行执行 subagents 审查
[模式:审查]
- 使用
Agent 工具在同一轮并行启动多个 subagents
- 每个 subagent 只负责自己的审查范围
- 每个 subagent 输出:
- 问题级别:Critical / Major / Minor / Suggestion
- 具体位置:
file_path:line_number
- 问题描述、原因、必要时给出修复建议
- 主线程等待所有 subagents 返回后,才能进入下一阶段
🔀 阶段 4:主线程综合反馈并归档审查结果
[模式:综合]
- 收集所有 subagents 审查结果
- 合并重复问题,保留最具体的证据与定位
- 按严重程度分类:Critical / Major / Minor / Suggestion
- 给出总体评价:是否可合并、主要风险点、建议优先级
- 生成并写入
.claude/review/<功能名>.md 审查报告,内容必须为 Markdown,建议结构如下:
## 📋 审查报告:<任务名称>
### 审查范围
- 变更文件:<数量> | 代码行数:+X / -Y
### 总体评价
- 代码质量:[优秀/良好/需改进]
- 是否可合并:[是/否/需修复后]
### 关键问题 (Critical)
> 必须修复才能合并
1. <问题描述>
### 主要问题 (Major)
1. <问题描述>
### 次要问题 (Minor)
1. <问题描述>
### 建议 (Suggestion)
1. <建议内容>
⛔ 阶段 4 结束:审查报告交付(非执行)
/ac-review 在此阶段必须执行以下动作:
-
创建并写入 .claude/review/<功能名>.md
-
向用户展示完整审查报告内容(直接输出报告 Markdown 正文,不得只给摘要、只提示已保存,或仅让用户自己打开文件)
-
以加粗文本输出提示(必须使用实际保存的文件路径):
📋 审查报告已生成并保存至 .claude/review/实际功能名.md
请先审查上述报告,并确认整改范围:告诉我哪些问题需要修改,哪些暂不修改。
- 你可以按问题级别选择:例如“只修 Critical 和 Major”
- 也可以按具体条目选择:例如“修第 1、2、4 条,其余先不动”
确认后我会生成执行计划文件:
.claude/plan/review-实际功能名.md
后续在实施计划生成后,请用户审查满意后,手动执行:
/ac-execute .claude/plan/review-实际功能名.md
⚠️ 注意:上面的 实际功能名.md 必须替换为你实际保存的文件名!**
-
立即终止当前回复(Stop here. No more tool calls.)
⚠️ 绝对禁止:
- ❌ 只在对话里打印结果而不落盘
- ❌ 只提示已写入文件,不展示审查报告正文
- ❌ 未经用户确认整改范围,直接生成执行计划
- ❌ 直接修改产品代码
- ❌ 自动调用
/ac-execute 或任何实施动作
整改范围确认后
当用户明确说明“哪些问题要改、哪些先不改”后:
📌 阶段 5:生成整改实施计划
[模式:计划]
- 仅基于用户确认要修改的问题范围生成计划
- 对用户明确排除的问题:
- 生成并写入
.claude/plan/review-<功能名>.md,内容必须为 Markdown,建议结构如下:
## 📋 实施计划:review-<任务名称>
### 来源审查报告
- `.claude/review/<功能名>.md`
### 本次处理范围
- <要修的问题列表>
### 暂不处理项
- <本轮不修改的问题列表>
### 实施步骤
1. <步骤 1>
2. <步骤 2>
### 关键文件
| 文件 | 操作 | 说明 |
|------|------|------|
| path/to/file.ts:L10-L50 | 修改 | 描述 |
### 风险与验证
| 风险 | 缓解/验证方式 |
|------|---------------|
| <风险> | <验证方式> |
⛔ 阶段 5 结束:实施计划交付(非执行)
-
创建并写入 .claude/plan/review-<功能名>.md
-
向用户展示完整实施计划
-
以加粗文本输出提示(必须使用实际保存的文件路径):
📋 实施计划已生成并保存至 .claude/plan/review-实际功能名.md
请审查上述计划,您可以:
- 🔧 修改计划:告诉我需要调整的部分,我会更新计划
- ▶️ 执行计划:复制以下命令到新会话执行
/ac-execute .claude/plan/review-实际功能名.md
⚠️ 注意:上面的 实际功能名.md 必须替换为你实际保存的文件名!**
-
立即终止当前回复(Stop here. No more tool calls.)
结果保存
- 审查报告:
.claude/review/<功能名>.md
- 实施计划:
.claude/plan/review-<功能名>.md
- 迭代版本:
.claude/review/<功能名>-v2.md、.claude/plan/review-<功能名>-v2.md...
写入应在向用户展示对应内容前完成。
结果修改流程
修改审查报告
如果用户要求修改审查结论:
- 根据用户反馈调整内容
- 更新
.claude/review/<功能名>.md
- 重新展示修改后的审查报告
- 再次提示用户确认整改范围
修改实施计划
如果用户要求修改整改计划:
- 根据用户反馈调整内容
- 更新
.claude/plan/review-<功能名>.md
- 重新展示修改后的实施计划
- 再次提示用户审查或执行
后续步骤
用户先审查 review 报告、确认整改范围,并在后续审查实施计划满意后,手动执行:
/ac-execute .claude/plan/review-<功能名>.md
关键规则
- 无参数 = 审查 git diff – 自动获取当前变更
- git revision = 审查该次提交 – 自动获取指定提交的 patch 内容
- Claude 主线程统筹 + subagents 并行审查 – 不调用外部审查模型
- 先归档审查报告,再生成实施计划 – 两类产物职责必须分离
- 整改范围必须由用户确认 – 未确认前不得生成
.claude/plan/review-*.md
- 审查流程只读 – 审查阶段不修改产品代码