review

根据参数选择审查模式和审查目标：

**审查当前分支**：
- `/review` 或 `/review full` → 全量代码审查
- `/review quick` → 快速审查（一键 diff + 结论）
- `/review security` → 安全专项审查

**审查指定提交**：
- `/review <commit-hash>` → 审查单个提交（full 模式）
- `/review quick <commit-hash>` → 快速审查单个提交
- `/review security <commit-hash>` → 安全审查单个提交
- `/review <commit-hash> quick` → 参数顺序灵活

参数值：「$ARGUMENTS」

---

## 参数解析

首先解析参数，确定审查模式和目标：

```bash
# 解析参数
ARGS="$ARGUMENTS"
MODE="full"
TARGET=""

# 提取模式和目标
for arg in $ARGS; do
  case "$arg" in
    quick|security|full)
      MODE="$arg"
      ;;
    *)
      TARGET="$arg"
      ;;
  esac
done

# 如果指定了 commit，验证其有效性
if [ -n "$TARGET" ]; then
  if ! git rev-parse --verify "$TARGET^{commit}" >/dev/null 2>&1; then
    echo "❌ 错误：无效的 commit hash: $TARGET"
    echo ""
    echo "请检查："
    echo "1. commit hash 是否正确（可以是完整 hash 或短 hash）"
    echo "2. commit 是否存在于当前仓库"
    echo ""
    echo "提示：使用 'git log' 查看可用的 commit"
    exit 1
  fi

  # 获取完整 hash 和提交信息
  FULL_HASH=$(git rev-parse "$TARGET")
  COMMIT_MSG=$(git log -1 --pretty=format:"%s" "$TARGET")

  echo "### 审查范围"
  echo ""
  echo "**提交**: \`$FULL_HASH\`"
  echo "**信息**: $COMMIT_MSG"
  echo "**作者**: $(git log -1 --pretty=format:"%an <%ae>" "$TARGET")"
  echo "**时间**: $(git log -1 --pretty=format:"%ai" "$TARGET")"
  echo ""
fi
```

根据解析结果，执行对应模式的审查。

---

## 模式 1：full（默认）

你是一位资深的代码审查工程师，负责执行务实的代码审查。

核心原则：**净正向 > 完美**，只要变更整体上改善了代码质量，不要因小瑕疵阻塞。

### 变更信息

根据是否指定了 commit，使用 Bash 工具执行不同的 Git 命令获取变更信息：

**如果指定了 commit（TARGET 非空）**，依次执行：
- 提交记录：`git show --no-patch <TARGET>`
- 变更内容：`git show <TARGET>`

**如果审查当前分支**，依次执行：
- Git 状态：`git status`
- 变更文件：`git diff --name-only origin/HEAD...`
- 提交记录：`git log --no-decorate origin/HEAD...`
- 变更内容：`git diff --merge-base origin/HEAD`

### 审查框架

按以下优先级顺序审查：

#### 1. 架构设计（关键）
- 是否符合现有架构模式和系统边界
- 模块性和单一职责原则
- 是否存在不必要的复杂度

#### 2. 功能正确性（关键）
- 业务逻辑是否正确实现
- 边界条件和异常处理
- 并发和状态管理

#### 3. 安全性（必须）
- 输入验证和转义
- 认证授权检查
- 敏感信息处理

#### 4. 可维护性（重要）
- 代码清晰度和命名
- 注释说明意图而非机制
- 错误信息是否便于调试

#### 5. 测试（重要）
- 测试覆盖关键路径
- 测试边界条件和错误场景

#### 6. 性能（注意）
- N+1 查询问题
- 不必要的内存分配
- 缓存策略

#### 7. 文件规模（注意）
- 检查 diff 涉及的每个文件总行数，对照语言阈值（Java 300 / Go 400 / Vue 200 / TSX/JSX 200 / TS/JS 300 / Python 300）
- 超限文件标记为 `[Improvement]`，给出具体拆分建议（按职责拆分、提取子组件、抽工具类等）
- 阈值详见 `rules/file-size-limit.md`

#### 8. 重构安全（注意）

检查是否存在重构风险：

**表格/列表重构**：
- 列数、列名、列顺序是否与原始代码一致
- 是否遗漏列或添加多余列
- 条件分支（if/else）是否都已正确处理

**数据结构重构**：
- 字段是否完整，没有遗漏
- 字段顺序是否一致（如果顺序重要）
- 字段类型是否一致

**条件分支重构**：
- 所有 if/else/switch 分支是否都已处理
- 是否存在"只处理一个分支，推测其他分支"的情况

**检查方法**：
1. 使用 `git show <commit>:<file>` 查看原始代码
2. 制作对比清单（列/字段/配置项）
3. 标记不一致项为 `[Critical]`

**依赖方向检查**（服务/模块拆分时）：
- 拆分后是否存在循环依赖（A → B → A）
- 子模块回调父模块的方法是否为纯工具方法（是 → 应提取到独立类）
- Spring Boot 3.x 构造器循环依赖会导致启动失败
- 标记循环依赖为 `[Critical]`

#### 9. 字段映射安全（注意）

检查是否存在字段映射错误：

**dataIndex 字段名**：
- 字段名是否与原始代码一致
- 是否使用了可选字段（优先使用必填字段）
- 注意字段名的细微差异（changedAt vs createdAt）

**枚举映射完整性**：
- 枚举映射是否完整（对照原始代码逐个检查）
- 是否遗漏枚举值（如只保留 3 个，实际有 10 个）
- 枚举值的拼写是否正确（UPLOAD vs Upload）

**防御性编程**：
- 是否有空值检查（if (!val) return '-'）
- 日期格式化是否有异常捕获
- 枚举映射是否有默认值

**rowKey 安全**：
- rowKey 是否使用了可选字段
- rowKey 是否唯一

**检查方法**：
1. 使用 `git show <commit>:<file>` 查看原始代码
2. 对比字段名、枚举映射
3. 检查 TypeScript 类型定义中的可选字段
4. 标记不一致项为 `[Critical]`

### 输出格式

```markdown
### 代码审查报告

**总体评估**：[简要说明变更的整体质量和主要发现]

### 问题发现

#### [Critical] 严重问题
- **文件:行号**：[问题描述和原因]

#### [Improvement] 建议改进
- **文件:行号**：[建议和原理]

#### [Nit] 细节建议
- Nit: **文件:行号**：[小建议]

### 结论

[通过 / 需修改后通过 / 需重新设计]
```

### 要求

- 提供具体、可操作的反馈
- 解释建议背后的工程原理
- 保持建设性，假设开发者有良好意图
- 使用简体中文输出

### 下一步操作

审查完成后，根据结论执行：

**结论为「通过」**：直接结束，不询问。

**结论为「需修改后通过」或「需重新设计」**：

使用 AskUserQuestion 询问用户，提供以下选项和风险说明：

```
请选择处置方式：

1. 只修复严重问题（推荐）
   修复 [Critical]；[Improvement] 全部落到 .claude/tasks/tech-debt.md
   持续追踪。范围最小，风险最低。

2. 修复全部问题
   修复 [Critical] + [Improvement]。改动范围较大，可能改变现有代码
   行为，存在引入新问题的风险。

3. 全部归档为技术债
   本轮不修任何问题；所有 [Critical] + [Improvement] 都写入
   .claude/tasks/tech-debt.md。适合迭代尾声、临近发布。

4. 跳过
   不做任何修改，仅保留审查报告供参考。
```

用户选择 1 或 2 时，调用 Skill 工具执行 `/fix`，参数格式：
```
[code-review] 根据代码审查结果修复以下问题：
1. [文件:行号] 问题描述
2. [文件:行号] 问题描述
...
```

用户选择 1 或 3 时，**必须**在本回复末尾追加技术债清单（追加 `.claude/tasks/tech-debt.md`，无则创建）：

```markdown
## YYYY-MM-DD review 归档

- [ ] [文件:行号] 问题描述（来源：commit <短 hash> 的 review）
- [ ] [文件:行号] 问题描述
```

注意：
- [Nit] 类问题不纳入自动修复范围，不写入技术债
- 参数必须以 `[code-review]` 开头，触发 /fix 的变更范围约束
- **禁止使用"留给下次迭代"等悬空话术**——所有问题要么修要么归档，二选一

---

## 模式 2：quick

快速审查改动，直接输出问题和建议。

### 执行

根据是否指定了 commit，使用不同的命令获取改动：

**如果指定了 commit（TARGET 非空）**：
```bash
# 获取提交统计
git show --stat $TARGET

# 获取提交变更
git show $TARGET
```

**如果审查当前分支**：
```bash
# 获取改动统计
git diff --stat

# 获取改动内容
git diff
```

直接输出审查结果，不需要用户确认。

### 输出格式

```
## 改动概览
[文件列表和改动行数]

## 问题（必须修复）
- [ ] 问题1
- [ ] 问题2

## 建议（每条必须打标签，三选一）
- ✅ [文件:行号] 建议内容              ← 本轮立即修复
- 📝 [文件:行号] 建议内容 → 追踪：<去向>  ← 落地为技术债
- ❌ [文件:行号] 建议内容 → 理由：<理由>  ← 明确拒绝

## 结论
✅ 可以提交 / ⚠️ 建议修复后提交 / ❌ 需要修复
```

**建议分类强制规范**（避免反复 review 提同样建议）：

| 标签 | 含义 | 必填字段 |
|------|------|---------|
| ✅ 本轮立即修复 | 本次 PR 内可低成本修复，纳入下一步 `/fix` 入参 | 修复策略一句话 |
| 📝 落地为技术债 | 当前 PR 不修，必须有追踪去向 | `→ 追踪：<issue 编号 / .claude/tasks/tech-debt.md 条目 / next-iteration>` |
| ❌ 拒绝 | 明确不修 | `→ 理由：<原代码遗留 / 违反 [code-review] 约束 / 业务无关 / 风险大于收益>` |

**禁用措辞**（不允许悬空建议）：
- ❌ "留给下次迭代"、"后续可以考虑"、"建议未来"、"可在下一版处理"
- ❌ 只写建议不带去向

理由：相同建议在多轮 review 里反复出现会浪费 token 和注意力，所有建议都必须有明确归宿。

**quick 模式的 📝 项处置**：quick 模式不弹 AskUserQuestion、不自动写入 `tech-debt.md`，所有 📝 项的「追踪去向」由用户在看到报告后**手动**追加到 `.claude/tasks/tech-debt.md`（或指定的追踪系统）。如需自动归档，请改用 `/review`（full 模式）。

不要啰嗦，直接给结论。

---

## 模式 3：security

对代码变更进行安全审查。

### 上下文信息

使用 Bash 工具执行以下命令获取上下文：

**如果指定了 commit（TARGET 非空）**：
- 提交信息：`git show --no-patch <TARGET>`
- 变更内容：`git show <TARGET>`

**如果审查当前分支**：
- Git 状态：`git status`
- 变更文件：`git diff --name-only origin/HEAD...`，失败回退 `git diff --name-only HEAD~5`
- 变更内容：`git diff --merge-base origin/HEAD`，失败回退 `git diff HEAD~5`

### 审查目标

识别 **高置信度** 的安全漏洞，只报告 >80% 确信可被利用的问题。

### 审查范围

#### 输入验证漏洞
- SQL 注入、命令注入、路径遍历
- XSS（仅不安全的 innerHTML 赋值方法）

#### 认证与授权
- 认证绕过、权限提升、会话管理缺陷

#### 密钥与加密
- 硬编码密钥/密码、弱加密算法、证书验证绕过

#