forge-review

文档落地路径：遵循 forge-doc-policy 规范。完整白名单 + frontmatter schema 见 ~/.claude/skills/forge-doc-policy/doc-paths.md。 当前文档加载顺序：需要判断需求/设计/工程口径时，先读项目 CLAUDE.md、 docs/README.md、docs/INDEX.md 和相关根级当前真相源；历史 archive 只作追溯证据。 详细规则见 ~/.claude/skills/_shared/current-doc-loading.md。

/forge-review：代码审查

前置脚本（每次先运行）

_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "当前分支: $_BRANCH"

---

提问格式与批量策略见 ~/.claude/skills/_shared/interaction-protocol.md。

---

第0步：确定基础分支

按顺序判断此 PR 合并到哪个分支：

# 1. 检查是否已有 PR
gh pr view --json baseRefName -q .baseRefName 2>/dev/null

# 2. 没有 PR 则获取仓库默认分支
gh repo view --json defaultBranchRef -q .defaultBranchRef.name 2>/dev/null

# 3. 都失败则回退到 main

打印出基础分支名称，后续所有 git diff、git fetch、git merge 等命令中用实际分支名替换"基础分支"。

---

第1步：检查分支状态

git branch --show-current
git fetch origin <基础分支> --quiet && git diff origin/<基础分支> --stat

如果在基础分支上，或没有 diff，输出："没有可审查的内容——你在基础分支上或没有变更。" 并停止。

---

第2步：获取完整 diff

git fetch origin <基础分支> --quiet
git diff origin/<基础分支>

在评论之前先读完完整 diff。 不要标记 diff 中已经修复的问题。

---

第3步：两轮审查

第一轮（严重问题）

逐项检查以下类别，对每个 diff 文件详细分析：

1. SQL 与数据安全

检查：

• 用户输入是否直接拼入 SQL？（注入风险）
• 原始 SQL 查询是否使用了参数化？
• 批量更新/删除是否有 WHERE 条件？（全表操作风险）
• 事务边界是否正确？（部分成功状态）
• 软删除记录是否在所有查询中被过滤了？

报告格式：[严重] 文件:行号 — 问题描述 → 修复建议

2. 竞态条件与并发

检查：

• 先读后写操作是否有并发安全问题？（检查-再-操作 TOCTOU）
• 数据库操作是否需要乐观锁/悲观锁？
• 共享状态是否在多个请求间安全？
• 缓存失效是否有竞态？

特别注意：状态转换（如 draft → published）必须用数据库级约束，不能只依赖应用层检查。

3. LLM 输出信任边界

检查：

• LLM 生成的内容在写入数据库前是否经过验证/清洗？
• LLM 输出是否直接用于 SQL 构建或系统命令？
• 是否对 LLM 输出的类型和格式做了断言？
• Prompt 中是否包含了敏感数据（密钥、PII）？

4. 枚举与值完整性

检查：

• 新增枚举值/状态/类型时，所有引用了同级值的文件是否都处理了新值？

重要：枚举完整性必须读取 diff 以外的代码。当 diff 新增了枚举值，用 Grep 找出所有引用了同级值的文件，Read 这些文件检查新值是否被处理。

第二轮（信息性问题）

5. 条件副作用

检查：

• 副作用（发邮件、写日志、扣费用）是否在 if 语句的所有分支中都正确处理？
• 删除或禁用功能时，是否清理了对应的副作用触发器？

6. 魔法数字与字符串耦合

检查：

• 是否有应该提取为常量的重复数字/字符串？
• 硬编码的限制值（如 100、1000）是否有注释说明含义？