xmwork/.claude/commands/review-pr.md

description, argument-hint

description	argument-hint
深度 review 一个 PR，评论式输出，不自动 approve	<pr-url-or-number> [--repo <repo-name>]

对 PR $1 做深度 review。

参数解析

• 如果 $1 是完整 URL（含 github.com），直接用
• 如果 $1 是纯数字，必须有 --repo xxx 指定仓库
• 如果只给数字、无 --repo，尝试从当前 pwd 推断仓库，否则报错要求补参

审查步骤

1. 拉 PR 到本地

gh pr checkout <number> --repo <org>/<repo>

2. 理解意图

• 读 PR 描述、linked issue
• 扫一眼 commit messages
• gh pr view <n> --json ... 看 CI 状态

3. 按顺序检查（每一层发现问题立即记录，不要停）

A. 正确性

• 逻辑是否和 PR 描述一致？
• 边界条件：空输入、极大值、并发、重入
• 错误处理：是否吞异常？日志是否丢了关键信息？

B. 架构一致性

• 是否符合本仓库现有分层（参考 ai-ops/CLAUDE.md 的仓库职责描述）？
• 是否产生了新的循环依赖？
• Casdoor JWT 字段、chat-gw 工具注册等跨仓库契约是否被破坏？

C. 安全

• SQL 拼接？SSRF？未鉴权接口？
• 敏感字段泄露到日志/响应？
• 依赖是否引入新 CVE？

D. 测试

• 是否有新测试？
• 测试是否真 cover 到改动路径（不只是 happy path）？
• 是否有 flaky 风险（时间依赖、随机、外部服务）？

E. 性能

• N+1 查询？
• 新增同步 IO？
• 大 response 体？

F. 代码质量

• 命名、注释、无用代码、TODO/FIXME
• 是否遵循仓库既有风格（读 2-3 个邻近文件比较）

4. 本地验证

如果可行：

• 跑本仓库标准测试命令（参考 ai-ops CLAUDE.md）
• 关键路径手工触发一次（如果有 fixture）

5. 输出

生成结构化 review，用 gh pr review <n> --comment --body-file /tmp/review.md 以评论形式发（不 approve，不 request-changes，除非有明确的 Critical 问题）。

格式：

## 🤖 Agent Review

### ✅ 做得好的地方
- ...

### ⚠️ 建议 (nit)
- `path/to/file.py:L42` — 建议改成 X，因为 Y

### ❌ 需要修改 (important)
- `path/to/file.py:L67` — **Bug**: 当 input 为空时会 NoneError；建议加 guard

### 🔴 必须修改 (critical)
- `path/to/migration.py` — 这个 migration 不可逆，会丢数据

### 📊 本地验证结果
- pytest: ✅ 45 passed, 0 failed
- lint: ✅
- build: ✅

### 结论
- [ ] 所有 critical 已处理 → 可 merge
- [x] 有 critical 待处理 → 请作者修改后我再 review

红线

• ❌ 绝不 gh pr review --approve
• ❌ 绝不 gh pr merge
• ❌ 不要 push commit 到 PR 分支（作者自己改）
• ❌ 不要把 review 发成 --request-changes（太强硬），除非明确发现会导致数据丢失 / 安全漏洞 / 破坏生产
• ✅ 只发 comment 式 review，让人类开发者做最终决策