# Ac Review

> 代码审查：无参数时自动审查 git diff，支持按 git revision 审查指定提交，并在确认整改范围后生成执行计划。

- Skill: `yz0812/ac-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add yz0812/ac-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/yz0812/ac-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: yz0812 (https://skillmd.com/u/yz0812)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/yz0812/ac-review

---


# Review - 审查归档 + 整改计划生成

由 Claude 在当前会话内完成代码审查。无参数时自动审查当前 git 变更，也可传入 git revision 审查指定提交；审查过程中由主线程统筹，并通过 subagents 并行执行子任务。主线程先汇总结果并写入 **`.claude/review/<功能名>.md`** Markdown 审查报告；当用户确认“哪些要改、哪些不改”后，再生成并写入 **`.claude/plan/review-<功能名>.md`** Markdown 实施计划。

## 使用方法

```bash
/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。默认至少拆成以下两个方向：

1. **正确性与回归风险审查**
   - 检查逻辑错误、边界条件、空值/异常路径、潜在回归
2. **可维护性与集成风险审查**
   - 检查命名与职责、重复逻辑、测试缺口、跨模块/接口一致性

若变更范围较大，可继续按文件组、模块或专题新增子任务，但必须保持“可并行、职责清晰、结果可汇总”。

### 🔬 阶段 3：并行执行 subagents 审查

`[模式：审查]`

1. 使用 `Agent` 工具在**同一轮**并行启动多个 subagents
2. 每个 subagent 只负责自己的审查范围
3. 每个 subagent 输出：
   - 问题级别：Critical / Major / Minor / Suggestion
   - 具体位置：`file_path:line_number`
   - 问题描述、原因、必要时给出修复建议
4. 主线程等待所有 subagents 返回后，才能进入下一阶段

### 🔀 阶段 4：主线程综合反馈并归档审查结果

`[模式：综合]`

1. 收集所有 subagents 审查结果
2. 合并重复问题，保留最具体的证据与定位
3. 按严重程度分类：Critical / Major / Minor / Suggestion
4. 给出总体评价：是否可合并、主要风险点、建议优先级
5. 生成并写入 **`.claude/review/<功能名>.md`** 审查报告，内容必须为 Markdown，建议结构如下：

```markdown
## 📋 审查报告：<任务名称>

### 审查范围
- 变更文件：<数量> | 代码行数：+X / -Y

### 总体评价
- 代码质量：[优秀/良好/需改进]
- 是否可合并：[是/否/需修复后]

### 关键问题 (Critical)
> 必须修复才能合并
1. <问题描述>

### 主要问题 (Major)
1. <问题描述>

### 次要问题 (Minor)
1. <问题描述>

### 建议 (Suggestion)
1. <建议内容>
```

### ⛔ 阶段 4 结束：审查报告交付（非执行）

**`/ac-review` 在此阶段必须执行以下动作**：

1. 创建并写入 `.claude/review/<功能名>.md`
2. 向用户展示完整审查报告内容（直接输出报告 Markdown 正文，不得只给摘要、只提示已保存，或仅让用户自己打开文件）
3. 以**加粗文本**输出提示（必须使用实际保存的文件路径）：

   ---
   **📋 审查报告已生成并保存至 `.claude/review/实际功能名.md`**

   **请先审查上述报告，并确认整改范围：告诉我哪些问题需要修改，哪些暂不修改。**
   - 你可以按问题级别选择：例如“只修 Critical 和 Major”
   - 也可以按具体条目选择：例如“修第 1、2、4 条，其余先不动”

   **确认后我会生成执行计划文件：**

   ```
   .claude/plan/review-实际功能名.md
   ```

   **后续在实施计划生成后，请用户审查满意后，手动执行：**

   ```
   /ac-execute .claude/plan/review-实际功能名.md
   ```
   ---

   **⚠️ 注意**：上面的 `实际功能名.md` 必须替换为你实际保存的文件名！**

4. **立即终止当前回复**（Stop here. No more tool calls.）

**⚠️ 绝对禁止**：
- ❌ 只在对话里打印结果而不落盘
- ❌ 只提示已写入文件，不展示审查报告正文
- ❌ 未经用户确认整改范围，直接生成执行计划
- ❌ 直接修改产品代码
- ❌ 自动调用 `/ac-execute` 或任何实施动作

---

## 整改范围确认后

当用户明确说明“哪些问题要改、哪些先不改”后：

### 📌 阶段 5：生成整改实施计划

`[模式：计划]`

1. 仅基于**用户确认要修改的问题范围**生成计划
2. 对用户明确排除的问题：
   - 不纳入实施步骤
   - 只在“暂不处理项”中记录
3. 生成并写入 **`.claude/plan/review-<功能名>.md`**，内容必须为 Markdown，建议结构如下：

```markdown
## 📋 实施计划：review-<任务名称>

### 来源审查报告
- `.claude/review/<功能名>.md`

### 本次处理范围
- <要修的问题列表>

### 暂不处理项
- <本轮不修改的问题列表>

### 实施步骤
1. <步骤 1>
2. <步骤 2>

### 关键文件
| 文件 | 操作 | 说明 |
|------|------|------|
| path/to/file.ts:L10-L50 | 修改 | 描述 |

### 风险与验证
| 风险 | 缓解/验证方式 |
|------|---------------|
| <风险> | <验证方式> |
```

### ⛔ 阶段 5 结束：实施计划交付（非执行）

1. 创建并写入 `.claude/plan/review-<功能名>.md`
2. 向用户展示完整实施计划
3. 以**加粗文本**输出提示（必须使用实际保存的文件路径）：

   ---
   **📋 实施计划已生成并保存至 `.claude/plan/review-实际功能名.md`**

   **请审查上述计划，您可以：**
   - 🔧 **修改计划**：告诉我需要调整的部分，我会更新计划
   - ▶️ **执行计划**：复制以下命令到新会话执行

   ```
   /ac-execute .claude/plan/review-实际功能名.md
   ```
   ---

   **⚠️ 注意**：上面的 `实际功能名.md` 必须替换为你实际保存的文件名！**

4. **立即终止当前回复**（Stop here. No more tool calls.）

---

## 结果保存

- **审查报告**：`.claude/review/<功能名>.md`
- **实施计划**：`.claude/plan/review-<功能名>.md`
- **迭代版本**：`.claude/review/<功能名>-v2.md`、`.claude/plan/review-<功能名>-v2.md`...

写入应在向用户展示对应内容前完成。

---

## 结果修改流程

### 修改审查报告

如果用户要求修改审查结论：

1. 根据用户反馈调整内容
2. 更新 `.claude/review/<功能名>.md`
3. 重新展示修改后的审查报告
4. 再次提示用户确认整改范围

### 修改实施计划

如果用户要求修改整改计划：

1. 根据用户反馈调整内容
2. 更新 `.claude/plan/review-<功能名>.md`
3. 重新展示修改后的实施计划
4. 再次提示用户审查或执行

---

## 后续步骤

用户先审查 review 报告、确认整改范围，并在后续审查实施计划满意后，**手动**执行：

```bash
/ac-execute .claude/plan/review-<功能名>.md
```

---

## 关键规则

1. **无参数 = 审查 git diff** – 自动获取当前变更
2. **git revision = 审查该次提交** – 自动获取指定提交的 patch 内容
3. **Claude 主线程统筹 + subagents 并行审查** – 不调用外部审查模型
4. **先归档审查报告，再生成实施计划** – 两类产物职责必须分离
5. **整改范围必须由用户确认** – 未确认前不得生成 `.claude/plan/review-*.md`
6. **审查流程只读** – 审查阶段不修改产品代码