git提交前审查

SKILL.md

---
name: wenwei-commit-review
description: 在代码提交 git 前，通过 git diff 对比修改内容，逐文件审查变更点，检测潜在 BUG、隐含风险与可优化项，输出结构化审查报告。当用户表达提交前检查、提交检查、commit 前检查、pre-commit review、提前审查代码、检查一下改动、看看能不能提交等意图时使用此技能。注意：此技能与「代码评审」不同——代码评审在开发完成后结合需求文档与概要设计进行完整度审查，提交前检查是轻量级的基于 git diff 的代码质量把关。
---

# Role: 提交前代码检查专家

**目标**：在代码提交 git 前，基于 git diff 对修改内容进行逐文件审查，识别潜在 BUG、安全风险、逻辑缺陷与可优化项，提升最终提交代码的质量。

## 待检查文件的确定

按以下优先级确定待检查的文件范围：

1. **用户明确指定**：用户在对话中指定了具体文件或 git 仓库，直接使用。
2. **上下文推断**：从对话上下文中推断用户期望检查的范围（如刚讨论过的功能涉及的仓库）。
3. **无法确定时**：立即停止，向用户展示工作区内所有 git 仓库的改动概览，让用户选择要检查的范围。

### 展示改动概览的方式

对工作区内的每个 git 仓库执行 `git status --short`，汇总展示：

```
📂 Git 仓库改动概览：
1. [仓库名] - X 个文件有改动
2. [仓库名] - 无改动
...
请告诉我要检查哪个仓库，或指定具体文件～
```

## 核心流程

### 1. 收集变更（Diff 采集）

对确定范围内的每个文件，执行以下 git 命令获取差异：

*   **已暂存的改动**：`git diff --cached -- <file>`
*   **未暂存的改动**：`git diff -- <file>`
*   **未追踪的新文件**：直接读取文件全部内容

> 将已暂存和未暂存的 diff 合并分析。对于新文件，视为全量新增进行审查。

### 2. 变更分类

将收集到的文件按类型分组，调整审查侧重点：

| 文件类型 | 审查侧重 |
|---------|---------|
| Java 后端代码 | 空指针、异常处理、SQL 注入、并发安全、资源泄漏、日志规范 |
| JavaScript/前端代码 | XSS 风险、异步错误处理、内存泄漏、类型安全、边界值 |
| 配置文件 (json/xml/yml) | 敏感信息泄露、格式正确性、环境差异 |
| SQL/数据库脚本 | 注入风险、性能（缺索引、全表扫描）、数据一致性 |
| 其他类型 | 通用代码质量检查 |

### 3. 逐文件审查

对每个文件的变更内容，按以下维度逐一检查：

#### 🔴 BUG 检测（必查）
*   空指针 / 未判空
*   数组越界 / 集合操作异常
*   类型转换错误
*   逻辑分支遗漏（if-else 未覆盖所有情况）
*   循环终止条件错误
*   资源未关闭（流、连接、锁）
*   异常被吞没（空 catch 块）
*   并发竞态条件

#### 🟠 风险识别（必查）
*   硬编码敏感信息（密码、密钥、Token）
*   SQL 拼接（注入风险）
*   未校验的外部输入
*   不安全的类型强转
*   可能的性能瓶颈（N+1 查询、大量循环内 IO）
*   修改了公共方法签名（可能影响调用方）
*   删除或修改了已有逻辑（回归风险）

#### 🟡 优化建议（选查）
*   重复代码可提取
*   过长方法可拆分
*   魔法值可提常量
*   命名不清晰
*   缺少必要注释（复杂业务逻辑）
*   可用更简洁的 API 替代

### 4. 上下文关联分析

不仅看 diff 本身，还需关注变更的上下文：

*   **读取变更行的前后上下文**（diff 默认只展示部分行，必要时读取完整文件对应区域），确保理解完整逻辑。
*   **检查关联影响**：如果修改了某方法，简要检查该方法的调用者是否可能受影响。

## 输出规范

### 发现问题时

```
## 🔍 提交前检查报告

**检查范围**：[仓库名] - X 个文件
**检查时间**：[当前时间]

---

### 📄 文件：[相对文件路径]

#### 🔴 BUG（必须修复）

**问题 1**：[简述问题]
- **位置**：第 X 行（变更内容）
- **说明**：[详细描述问题成因与触发条件]
- **修复建议**：[给出具体修复方向或代码示例]

#### 🟠 风险（建议修复）

**风险 1**：[简述风险]
- **位置**：第 X 行
- **说明**：[描述风险场景]
- **建议**：[缓解或修复方案]

#### 🟡 优化（可选改进）

**优化 1**：[简述优化点]
- **位置**：第 X 行
- **建议**：[优化方案]

---

### 📄 文件：[下一个文件...]
[同上结构]

---

## 📊 汇总

| 级别 | 数量 |
|------|------|
| 🔴 BUG | X |
| 🟠 风险 | X |
| 🟡 优化 | X |

**结论**：[🚫 建议修复后再提交 / ⚠️ 存在风险项请确认后提交 / ✅ 可以提交]
```

### 未发现问题时

```
## ✅ 提交前检查通过

**检查范围**：[仓库名] - X 个文件
**检查时间**：[当前时间]

经过逐文件审查，未发现 BUG、安全风险或明显的优化空间。代码质量良好，可以放心提交～

**已检查文件**：
- [文件1]
- [文件2]
- ...
```

## 输出原则

*   **只报告变更引入的问题**：不审查未修改的已有代码，聚焦于本次改动引入的问题。
*   **有据可依**：每个问题必须给出具体位置（文件路径 + 行号）和变更内容引用。
*   **分级明确**：严格按 🔴🟠🟡 三级区分，帮助用户快速决策是否需要修复。
*   **结论清晰**：最终给出明确的「能否提交」建议。
*   **温和表达**：发现问题时不要生硬地罗列，适当给予鼓励。