PR 审查
- 作者仓库星标 184,730
- 作者仓库 AutoGPT
PR Review
Find the PR
gh pr list --head $(git branch --show-current) --repo Significant-Gravitas/AutoGPT
gh pr view {N}
Read the PR description
Before reading code, understand the why, what, and how from the PR description:
gh pr view {N} --json body --jq '.body'
Every PR should have a Why / What / How structure. If any of these are missing, note it as feedback.
Read the diff
gh pr diff {N}
Fetch existing review comments
Before posting anything, fetch existing inline comments to avoid duplicates:
gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments --paginate
gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/reviews
What to check
Description quality: Does the PR description cover Why (motivation/problem), What (summary of changes), and How (approach/implementation details)? If any are missing, request them — you can't judge the approach without understanding the problem and intent.
Correctness: logic errors, off-by-one, missing edge cases, race conditions (TOCTOU in file access, credit charging), error handling gaps, async correctness (missing await, unclosed resources).
Security: input validation at boundaries, no injection (command, XSS, SQL), secrets not logged, file paths sanitized (os.path.basename() in error messages).
Code quality: apply rules from backend/frontend CLAUDE.md files.
Architecture: DRY, single responsibility, modular functions. Security() vs Depends() for FastAPI auth. data: for SSE events, : comment for heartbeats. transaction=True for Redis pipelines.
Testing: edge cases covered, colocated *_test.py (backend) / __tests__/ (frontend), mocks target where symbol is used not defined, AsyncMock for async.
Output format
Every comment must be prefixed with 🤖 and a criticality badge:
| Tier | Badge | Meaning |
|---|---|---|
| Blocker | 🔴 **Blocker** |
Must fix before merge |
| Should Fix | 🟠 **Should Fix** |
Important improvement |
| Nice to Have | 🟡 **Nice to Have** |
Minor suggestion |
| Nit | 🔵 **Nit** |
Style / wording |
Example: 🤖 🔴 **Blocker**: Missing error handling for X — suggest wrapping in try/except.
Post inline comments
For each finding, post an inline comment on the PR (do not just write a local report):
# 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>- 流狐分类
- 安全
- 作者声明 Agent
- 未找到明确声明;不据此推断已兼容或已测试
- 静态检查
- 88 / 100 · 启发式扫描,不代表运行安全
- 作者 / 版本 / 许可
- @Significant-Gravitas · 未声明 license
- 流狐 Token 估算
- 低消耗
- 流狐接入估算
- 即装即用
- 是否需要外部 API Key
- 未发现要求
- 检测到的系统要求
- 未声明
- 底层运行要求
- 未声明
- 检测到的文件与系统行为
-
- 只读
- 允许写入 / 修改
- 检测到的网络行为
- 允许外网请求
- 安装命令数
- 无(仅作为资料)
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
作者没有在当前 SKILL.md 中定义固定输出样例。 Find the PR
Before reading code, understand the why, what, and how from the PR description: Every PR should have a Why / What / How structure. If any of these are missing, note it as feedback.
Read the diff
Before posting anything, fetch existing inline comments to avoid duplicates:
Description quality: Does the PR description cover Why (motivation/problem), What (summary of changes), and How (approach/implementation details)? If any are missing, request them — you can't judge the approach without understanding the problem and intent.
Every comment must be prefixed with 🤖 and a criticality badge: Tier · Badge · Meaning Blocker · 🔴 Blocker · Must fix before merge
# PR Review
## Find the PR
```bash
gh pr list --head $(git branch --show-current) --repo Significant-Gravitas/AutoGPT
gh pr view {N}
```
## Read the PR description
Before reading code, understand the **why**, **what**, and **how** from the PR description:
```bash
gh pr view {N} --json body --jq '.body'
```
Every PR should have a Why / What / How structure. If any of these are missing, note it as feedback.
## Read the diff
```bash
gh pr diff {N}
```
## Fetch existing review comments
Before posting anything, fetch existing inline comments to avoid duplicates:
```bash
gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/comments --paginate
gh api repos/Significant-Gravitas/AutoGPT/pulls/{N}/reviews
```
## What to check
**Description quality:** Does the PR description cover Why (motivation/problem), What (summary of changes), and How (approach/implementation details)? If any are missing, request them — you can't judge the approach without understanding the problem and intent.
**Correctness:** logic errors, off-by-one, missing edge cases, race conditions (TOCTOU in file access, credit charging), error handling gaps, async correctness (missing `await`, unclosed resources).
**Security:** input validation at boundaries, no injection (command, XSS, SQL), secrets not logged, file paths sanitized (`os.path.basename()` in error messages).
**Code quality:** apply rules from backend/frontend CLAUDE.md files.
**Architecture:** DRY, single responsibility, modular functions. `Security()` vs `Depends()` for FastAPI auth. `data:` for SSE events, `: comment` for heartbeats. `transaction=True` for Redis pipelines.
… 作者原文负责流程事实;流狐只索引当前章节、要点、文件与命令。
章节 -> Find the PR → Read the PR description → Read the diff → Fetch existing review comments → What to check → Output format
要点 -> why · what · how · Description quality · Correctness · Security · Code quality · Architecture
文件/命令 -> await · os.path.basename() · Security() · Depends() · data: · : comment · transaction=True · test.py
内容 SHA-256 -> 55cad1260d20
原文结构
适用与边界
原文中的明确线索
await、os.path.basename()、Security()、Depends()、data:、: comment、transaction=True、test.py