code-review

name	code-review
description	多模型并行 Code Review。**自动触发场景**：用户拍板 plan 后改完代码（中等 / 复杂任务），AI 主动询问「需要 code review 吗？」**手动触发**：用户输入 `/code-review` 或说「review 一下这次改动 / 帮我看看这次提交」。按改动复杂度分级派 SubAgent，**轻量改动只派 1 个 sonnet 兜底，复杂任务才派 3 个含 opus 架构师**——不浪费最强模型在简单任务上。
argument-hint	["--staged / --last / --file <path>"]
allowed-tools	Bash(git *), Read

code-review

多模型并行 Code Review。按改动复杂度分级派 SubAgent，汇总后输出统一报告。

自动触发：完成开发后主动询问

参考 test-assist skill 的模式——用户拍板 plan + 代码改完后，AI 必问一次：

「这次改动需要 code review 吗？我可以派多模型并行审查：
 - 实现细节（sonnet）：bug / 边界条件 / 错误处理
 - 安全审计（haiku）：隐私泄露 / 凭据硬编码
 - 架构质量（opus）：模块边界 / 接口设计（仅复杂任务才派）
 yes / no」

触发边界

复杂度判据见 .claude/rules/im-agent-workflow.md 的「任务复杂度分级」表（单一权威源）。

改动复杂度	自动触发询问	派几个 agent	模型分配
简单（单文件 / 改注释 / 调样式 / 配置）	❌ 不问	用户手动调时只派 1 个	实现细节 sonnet 兜底
中等（2-3 文件 / 改测试 / 局部 refactor）	✅ 必问	派 2 个	实现细节 sonnet + 安全审计 haiku
复杂（≥3 文件 / 跨模块 / 改协议契约）	✅ 必问，强烈建议跑	派 3 个	实现细节 sonnet + 安全审计 haiku + 架构质量 opus
UI 样式 / 一次性 bug hotfix	❌ 不问（紧急 / 视觉判断 review 价值低）	用户手动调时按改动量	同上

同会话边界

• 用户首次回答 no → 同会话同分支不再重复问（一次拒绝就尊重）
• 用户回答 yes → 按复杂度派对应 agent 跑

与 git-ship 的关系

• 本 skill 是 git-ship 的前置可选环节：用户表达完成意图时（「完成了 / 可以提了」），先问 code-review 再问 ship
• 也可独立调（用户 /code-review，或开发中途想审一下）
• review 出 CRITICAL 问题 → 修完再 ship；只有 SUGGESTION → 用户决定要不要修

参数

$ARGUMENTS — 可选，指定 Review 范围。不传则 Review 当前分支相对 master 的所有变更。

支持格式：

• <空> — Review 当前分支 vs master 的全部 diff
• --staged — 只 Review 暂存区
• --last — 只 Review 最近一次 commit
• --file <path> — 只 Review 指定文件

执行流程

Step 1: 确定 Review 范围

# 默认: 当前分支 vs master
git diff master...HEAD

# --staged
git diff --cached

# --last
git diff HEAD~1..HEAD

# --file <path>
git diff master...HEAD -- <path>

同时获取：

git diff master...HEAD --stat   # 变更文件统计
git log master...HEAD --oneline  # commit 列表

如果 diff 为空，报告"无变更需要 Review"并终止。

Step 2: 判定改动复杂度

按 .claude/rules/im-agent-workflow.md 的「任务复杂度分级」表判定（见上文「触发边界」表）。

Step 3: 按复杂度派 SubAgent

3 类 agent 角色分工：

角色	关注点	模型	何时派
实现细节	bug / 边界条件 / 错误处理 / 性能 / 可读性	sonnet	简单 / 中等 / 复杂 都派（兜底）
安全审计	隐私泄露 / 注入 / 凭据硬编码 / 依赖安全	haiku	中等 / 复杂 派
架构质量	模块边界 / 职责单一 / 接口设计 / 向后兼容	opus	仅复杂任务派（避免 opus 浪费在小改动上）

派单原则：

• 多 agent 必须并行启动（run_in_background: true），不串行等待
• 简单任务用户手动调 → 只派实现细节 1 个，跑完即出报告
• 中等任务 → 派 2 个
• 复杂任务 → 派 3 个（含 opus 架构师）

Agent prompt 模板

你是 Code Review 的 {角色名} 审查员。

Review 范围:
- 分支: {当前分支} vs master
- 变更文件: {文件列表}
- Commit: {commit 列表}

变更内容:
{diff 内容}

你的审查重点是 **{关注点}**。

输出格式（严格遵循）:

## {角色名} Review

### 问题（按严重程度排序）

#### CRITICAL（阻断合并）
- **[文件:行号]** 问题描述
  建议修复: ...

#### WARNING（建议修复）
- **[文件:行号]** 问题描述
  建议修复: ...

#### SUGGESTION（可选优化）
- **[文件:行号]** 问题描述

### 亮点
- 做得好的地方（1-2 条）

### 总结
一句话总结：是否建议合并? (✅ 建议合并 / ⚠️ 修复后合并 / ❌ 不建议合并)

Step 4: 汇总报告

等待派出的 agent 全部完成后，汇总为统一报告：

# Code Review 报告

| 审查员 | 模型 | 结论 |
|--------|------|------|
| 实现细节 | sonnet | {✅/⚠️/❌} |
| 安全审计 | haiku | {✅/⚠️/❌} |（中等以上才有）
| 架构质量 | opus | {✅/⚠️/❌} |（仅复杂任务才有）

## CRITICAL 问题汇总（必须修复）
{合并各方的 CRITICAL，去重}

## WARNING 问题汇总（建议修复）
{合并各方的 WARNING，去重}

## SUGGESTION 汇总（可选）
{合并各方的 SUGGESTION，去重}

## 最终建议
{基于各方结论的综合判断}

去重规则：如果多个审查员指出同一文件同一行的同类问题，合并为一条并标注"多方指出"。

Step 5: 输出报告

将报告直接输出给用户。不写文件，不提交。

异常处理

• 某个 Agent 超时或失败 → 跳过该审查员，在报告中标注"未完成"，不阻塞其他结果
• diff 超过 2000 行 → 警告用户"变更量较大，Review 可能不够精细"，但仍执行
• diff 涉及生成代码（__generated__ / dist / node_modules）→ 过滤掉，只 review 业务代码

反模式（禁止）

• ❌ 简单任务自动询问 code review（噪音）
• ❌ 简单任务派 3 个 agent 含 opus（浪费 token，价值低）
• ❌ 复杂任务跳过 opus 架构师（架构问题 sonnet 推理不够深）
• ❌ 用户已经说 no 同会话又问一遍（不尊重）
• ❌ 串行启动 agent（必须并行 run_in_background: true）
• ❌ 在 Review 过程中执行 build / test（Review 是只读操作）

注意事项

• Review 是只读操作，不修改任何文件
• 输出中文
• 与 git-ship skill 配合使用：ship 前可选先跑一次 review，发现 CRITICAL 问题就先修再 ship