AgentSkillsCN

pr-review-assist

采用三阶段框架（情境、分析、验证）进行结构化的PR评审。适用于审查拉取请求、当用户分享PR链接，或提及“评审PR”“代码评审”或“检查这PR”的场景。

SKILL.md
--- frontmatter
name: pr-review-assist
description:  Prepare structured PR reviews using a three-phase framework (Context, Analysis, Validation). Use when reviewing pull requests, when user shares a PR URL, or mentions "review PR", "code review", or "check this PR".
allowed-tools:  Bash(gh: *) Read

PR Review Assist

Great code review isn't about catching bugs—it's about building confidence in what ships. Treat every PR as the beginning of a conversation.

Prerequisites

  • •gh CLI authenticated
  • •PR URL or repo/number (e.g., owner/repo#123)

For PR Authors

Before requesting review: self-review first, leave explanatory comments on non-obvious changes, split large PRs. Move to draft when addressing feedback.

Phase 1: Context Before Code

Establish strategic foundation before looking at diffs.

bash
gh pr view <number> --json title,body,author,files,additions,deletions,baseRefName,headRefName,labels

Business Context

  • •Who initiated this and why now?
  • •Which users/systems does this impact?
  • •What problem does this solve?
  • •How does this align with priorities?

Technical Context

  • •What's the blast radius if this fails?
  • •Are there dependencies or sequencing needs?
  • •Does this require cross-team coordination?
  • •What validation environments exist?

Phase 2: Systematic Analysis

Scope & Structure

  • •Is the PR appropriately sized?
  • •Are changes cohesive or should this be split?
  • •Do file changes align with stated intent?

Quality Analysis

AspectKey Questions
IntentDoes code match PR description?
CorrectnessEdge cases, null handling, logic errors?
SecurityInput validation, auth, data exposure?
PerformanceN+1 queries, loops, memory?
AccessibilityKeyboard, alt text, ARIA?
TestingCoverage gaps?
PatternsFollows repo conventions?

Related Context

Optionally search your local notes or documentation for related context:

bash
# Customize these paths to your own notes/docs directory
grep -r "<keywords>" "<your-notes-directory>/"

Phase 3: Validation

See review-checklist.md for detailed verification steps.

Mindset: Trust your team. Preferences (💅) don't block; only true blockers (🟡) that would break prod or harm users.

Actions:

  • •Approve: Ships safely
  • •Request Changes (🟡): Blockers only
  • •Comment (🙋): Need answers first

After: Respond to replies, react with emoji, link back in follow-ups.

Output

markdown
## PR Review:  <title>

**PR**:  <url> | **Author**: @<author> | **Files**: <count>

### Context
[Why now, impact, blast radius]

### Analysis
[Approach assessment, observations with file: line refs]

### Recommendation
[Approve/Request Changes/Comment] — [rationale]

Example Usage

"Review this PR: https://github.com/org/repo/pull/123" "Help me review #1642"

Inspiration