pr-review

PR 审查

查找 PR

gh pr list --head $(git branch --show-current) --repo Significant-Gravitas/AutoGPT
gh pr view {N}

阅读 PR 描述

阅读代码前，先从 PR 描述中了解原因、内容和方式：

gh pr view {N} --json body --jq '.body'

每个 PR 都应采用「Why / What / How」结构。如果缺少其中任何一项，请将其作为反馈指出。

阅读差异

gh pr diff {N}

获取现有审查评论

发布任何评论前，先获取现有的行内评论，以免重复：

gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments --paginate
gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/reviews

检查内容

描述质量： PR 描述是否涵盖 Why（动机／问题）、What（变更概述）和 How（方案／实现细节）？如果有任何缺失，请要求补充——不了解问题和意图，就无法评估方案。

正确性： 逻辑错误、差一错误、遗漏边界情况、竞态条件（文件访问、扣费中的 TOCTOU）、错误处理缺失、异步正确性（遗漏 await、未关闭资源）。

安全性： 边界处的输入校验、无注入风险（命令、XSS、SQL）、不记录机密信息、清理文件路径（在错误消息中使用 os.path.basename()）。

代码质量： 遵循后端／前端 CLAUDE.md 文件和根目录 AGENTS.md 中的规则，包括其中的「面向用户的文案」部分（面向用户的文字应使用 workflow，不能使用 agent 或 graph）。

架构： DRY、单一职责、模块化函数。FastAPI 身份验证使用 Security() 还是 Depends()。SSE 事件使用 data:，心跳使用 : comment。Redis 管道使用 transaction=True。

测试： 是否覆盖边界情况、测试文件是否与代码放在一起：后端使用 *_test.py，前端使用 __tests__/；mock 的目标应是符号使用的位置，而不是定义的位置；异步代码使用 AsyncMock。

输出格式

每条评论都必须以 🤖 和严重级别徽标开头：

级别	徽标	含义
阻塞	🔴 **Blocker**	合并前必须修复
应修复	🟠 **Should Fix**	重要改进
可改进	🟡 **Nice to Have**	次要建议
小问题	🔵 **Nit**	风格／措辞

示例：🤖 🔴 **Blocker**: 缺少对 X 的错误处理——建议使用 try/except 包装。

发布行内评论

对于每个发现，都在 PR 上发布行内评论（不要只写本地报告）：

# Get the latest commit SHA for the PR
COMMIT_SHA=$(gh api repos/Significant-Gravitas/AutoGPT/pulls/{N} --jq '.head.sha')

# Post an inline comment on a specific file/line
gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments \
  -f body="🤖 🔴 **Blocker**: <description>" \
  -f commit_id="$COMMIT_SHA" \
  -f path="<file path>" \
  -F line=<line number>