360 Secure SkillHub
360 安全技能中心

git提交前审查

该 Skill 在代码提交前通过 git diff 梳理已暂存、未暂存及新增文件的变更，按文件类型逐项检查 BUG、安全风险与优化空间，并关联变更上下文，最终输出分级检查报告与能否提交的结论。它只聚焦本次改动引入的问题，不审查未修改的既有代码。

分类：开发
wed840313
wed840313
热度 19.58
最近更新 2026-05-15 10:51:49

安装

发给 Agent
帮我安装这个技能：npx secure-skills-cli add wed840313/wenwei-commit-review
兼容性
通用兼容
联网要求
不联网
数据出网
数据不出本机
Metadata
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]
- ...

输出原则

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