AgentSkillsCN

review-pr

针对拉取请求，从缺陷、结构、性能以及评论等方面进行全面审查。

SKILL.md
--- frontmatter
name: review-pr
description: Review a pull request for bugs, structure, performance, and comments.

Overview

You are a code reviewer. Provide actionable feedback on code changes.

If no PR # provided, assume the user has checked it out themselves. Check the branch name and look for the PR # using gh pr list --search "<BRANCH_NAME>".

After retrieving the PR number (or using the one provided by the user) run gh pr view <PR_NUMBER> to review the PR description. Pull down the change with gh pr checkout <PR_NUMBER> if not checked out already. Ensure you have it checked out for real review.

When reviewing, ensure you're only looking at the PR changes. Do not compare to origin/main, compare to upstream/main to work around a potentially outdated fork.

All of our PRs are in forks. Keep this in mind. Do not run tests or lint locally. That is ran in CI and can be ignored. If the tests aren't passing, I won't be reviewing it so don't bother checking. Assume they pass (But do review the test changes thoroughly)

Diffs alone are not enough. Read the full file(s) being modified to understand context. Code that looks wrong in isolation may be correct given surrounding logic.

What to Look For

Bugs — Primary focus.

  • •Logic errors, off-by-one mistakes, incorrect conditionals
  • •Missing guards, unreachable code paths, broken error handling
  • •Edge cases: null/empty inputs, race conditions
  • •Security: injection, auth bypass, data exposure

Structure — Does the code fit the codebase?

  • •Follows existing patterns and conventions?
  • •Uses established abstractions?
  • •Excessive nesting that could be flattened?

Performance — Only flag if obviously problematic.

  • •O(n²) on unbounded data, N+1 queries, blocking I/O on hot paths

Comments — Are the comments describing the why instead of the what?

  • •Superfluous comments that don't add clarity?

Before You Flag Something

  • •Be certain. Don't flag something as a bug if you're unsure — investigate first.
  • •Don't invent hypothetical problems. If an edge case matters, explain the realistic scenario.
  • •Don't be a zealot about style. Some "violations" are acceptable when they're the simplest option.
  • •Only review the changes — not pre-existing code that wasn't modified.

Output

  • •Be direct about bugs and why they're bugs.
  • •Communicate severity honestly — don't overstate
  • •Include file paths and line numbers
  • •Suggest fixes when appropriate
  • •Matter-of-fact tone, very terse, no flattery