代码审查请求

提交前审查：安全扫描、质量门禁、自动修复

概述

代码合入前的自动化验证流水线。静态扫描、基线感知质量门禁、独立审查子代理，以及自动修复循环。

核心原则：任何代理都不应验证自己的工作。全新上下文能发现你遗漏的问题。

使用场景

• 实现功能或修复Bug后，在 git commit 或 git push 之前
• 当用户说commit、push、ship、done、verify或review before merge时
• 在git仓库中完成2个以上文件编辑的任务后
• 子代理驱动开发中每个任务之后（双阶段审查）

跳过：仅文档变更、纯配置调整、或用户说跳过验证时。

本技能 vs github-code-review：本技能验证你的更改在提交前是否有问题。github-code-review 审查GitHub上其他人的PR并添加行内评论。

步骤1 —— 获取diff

git diff --cached

如果为空，尝试 git diff，然后 git diff HEAD~1 HEAD。

如果 git diff --cached 为空但 git diff 显示变更，告诉用户先 git add files。如果仍为空，运行 git status——没有需要验证的内容。

如果diff超过15,000字符，按文件拆分：git diff --name-only 然后 git diff HEAD -- specific_file.py。

步骤2 —— 静态安全扫描

仅扫描新增行。任何匹配都是安全问题，将输入步骤5。

# 硬编码密钥
git diff --cached | grep "^+" | grep -iE "(api_key|secret|password|token|passwd)\\s*=\\s*['\"][^'\"]{6,}['\"]"

# Shell注入
git diff --cached | grep "^+" | grep -E "os\\.system\\(|subprocess.*shell=True"

# 危险的eval/exec
git diff --cached | grep "^+" | grep -E "\\beval\\(|\\bexec\\("

# 不安全的反序列化
git diff --cached | grep "^+" | grep -E "pickle\\.loads?\\("

# SQL注入
git diff --cached | grep "^+" | grep -E "execute\\(f\"|\\.format\\(.*SELECT|\\.format\\(.*INSERT"

步骤3 —— 基线测试和代码检查

检测项目语言并运行相应工具。在变更前捕获失败数量作为基线失败数（暂存变更、运行、恢复）。只有你的变更引入的新失败才会阻止提交。

测试框架按项目文件自动检测：Python用pytest，Node用npm test，Rust用cargo test，Go用go test。

代码检查和类型检查仅在已安装时运行：Python用ruff和mypy，Node用eslint和tsc，Rust用cargo clippy，Go用go vet。

基线对比：如果基线是干净的而你的变更引入了失败，这就是回归。如果基线已有失败，只计算新增的。

步骤4 —— 自检清单

• [ ] 没有硬编码的密钥、API密钥或凭据
• [ ] 用户输入数据有验证
• [ ] SQL查询使用参数化语句
• [ ] 文件操作验证路径（无路径遍历）
• [ ] 外部调用有错误处理（try/catch）
• [ ] 没有遗留的debug print/console.log
• [ ] 没有注释掉的代码
• [ ] 新代码有测试（如果测试套件存在）

步骤5 —— 独立审查子代理

直接调用 delegate_task——它在 execute_code 或脚本内部不可用。

审查员只获取diff和静态扫描结果。与实现者无共享上下文。失败即关闭：无法解析的响应 = 失败。

独立审查员返回JSON格式：passed(布尔值)、security_concerns(数组)、logic_errors(数组)、suggestions(数组)、summary(一句话判定)。

失败即关闭规则：security_concerns或logic_errors非空则passed必须为false；无法解析diff则passed必须为false；只有两个列表都为空时才能设置passed=true。

步骤6 —— 评估结果

综合步骤2、3和5的结果。

全部通过：进入步骤8（提交）。有失败：报告失败内容，然后进入步骤7（自动修复）。

步骤7 —— 自动修复循环

最多2次修复-重新验证循环。生成第三个代理上下文——不是你（实现者），也不是审查员。它只修复报告的问题。

修复代理完成后，重新运行步骤1-6（完整验证循环）。通过则进入步骤8；失败且尝试次数小于2则重复步骤7；2次尝试后仍失败则将剩余问题上报给用户，并建议 git stash 或 git reset 撤销。

步骤8 —— 提交

如果验证通过：git add -A && git commit -m "[verified] description"。[verified] 前缀表示独立审查员批准了此变更。

参考资料：常见需要标记的模式

Python

# 差：SQL注入
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")
# 好：参数化
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

# 差：Shell注入
os.system(f"ls {user_input}")
# 好：安全的subprocess
subprocess.run(["ls", user_input], check=True)

JavaScript

// 差：XSS
element.innerHTML = userInput;
// 好：安全
element.textContent = userInput;

与其他技能的集成

子代理驱动开发：在每个任务后作为质量门禁运行此技能。双阶段审查（规范合规 + 代码质量）使用此流水线。测试驱动开发：此流水线验证是否遵循了TDD规范——测试存在、测试通过、无回归。编写计划：验证实现是否匹配计划需求。

常见陷阱

• 空diff——检查 git status，告诉用户没有需要验证的内容
• 不是git仓库——跳过并告诉用户
• 大diff——按文件拆分，分别审查
• delegate_task 返回非JSON——用更严格的提示重试一次，然后视为失败
• 误报——如果审查员标记了有意为之的内容，在修复提示中注明
• 未找到测试框架——跳过回归检查，审查员判定仍然运行
• 代码检查工具未安装——静默跳过该检查，不失败
• 自动修复引入新问题——算作新的失败，循环继续