pr-review

Security Community

Repo stars 184,730
Author repo AutoGPT

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Review a PR for correctness, security, code quality, and testing issues. TRIGGER when user asks to review a PR, check PR quality…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Find the PR”, “Read the PR description”, “Read the diff”, “Fetch existing review comments”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name pr-review directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Find the PR / Read the PR description / Read the diff” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

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>

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: Security
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @Significant-Gravitas · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: External requests
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview pr-review.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# 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.

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Find the PR → Read the PR description → Read the diff → Fetch existing review comments → What to check → Output format
terms    -> why · what · how · Description quality · Correctness · Security · Code quality · Architecture
files/cmd -> await · os.path.basename() · Security() · Depends() · data: · : comment · transaction=True · test.py
body sha256 -> 55cad1260d20