pr-review

PR Review Code Review Skill

Systematically review a Pull Request in stages: first verify requirement understanding and logical correctness, then perform multi-dimensional quality checks in parallel, and finally submit a review report.

Trigger Constraints: This skill must be explicitly named by the user as pr-review、$pr-review or "use the pr-review skill" before it can be used. Ordinary PR links,review 下这个 PR、帮我代码审查 and similar requests should not automatically trigger this skill.

Step 0: Pull the Code

Use the following commandNo need to switch branches, directly use the PR number:

# 获取 PR 基本信息
gh pr view <number> --json number,title,body,author,state,headRefName,baseRefName,additions,deletions,files

# 获取完整 diff
gh pr diff <number>

View commit history

gh pr view --json commits --jq '.commits[].messageHeadline'

Check CI status

gh pr checks


如需在本地运行 **tsc / 单元测试**，使用 `git worktree` 创建独立目录，**不影响当前分支**：

```bash
# 1. 拉取 PR 代码到临时分支
git fetch upstream pull/<number>/head:pr/<number>

# 2. 在独立目录检出（与当前工作区完全隔离）
git worktree add ~/pr-worktrees/pr-<number> pr/<number>

# 3. 进入该目录安装依赖、运行测试
cd ~/pr-worktrees/pr-<number>
pnpm install
pnpm tsc --noEmit          # 类型检查
pnpm test                  # 单元测试

# 4. 审查完毕后清理
cd -
git worktree remove ~/pr-worktrees/pr-<number>
git branch -D pr/<number>

Phase 1: Requirement Understanding and Logic Verification

Goal: Understand the intent of this PR, and reason about whether the test cases can pass by reading the code.

1.1 Requirement Summary

Read the PR title, description, and diff, and summarize in your own words:

What is the core purpose of this PR?
Which key modules were changed?
Are there any changes to external interfaces or data structures?

1.2 Test Reasoning

Act as a tester, and for the core changes of the PR,propose 3~5 key test cases, then find the corresponding logic in the code for reasoning and verification:

Normal path: Does the main flow run as expected?
Boundary conditions: Are boundaries such as null values, extreme values, and concurrency handled?
Exception path: Is the behavior correct when input is erroneous or a dependency fails?

Verification Method: Directly read the relevant code, reason about the execution path of each test case, and confirm that the logic can pass. If corresponding unit tests exist in the code, check them as well.

⚠️ Phase Gate

If Phase 1 findssevere ambiguity in requirement understandingoran obvious error in the core logic(such as test case reasoning being unable to pass),immediately skip the subsequent phases and go directly to the "Submit Comment" step, indicate the blocking reason in the report, and request the author to clarify or fix before continuing the review.

Phases 2 to 6: Parallel In-Depth Review

After Phase 1 passes,the following five phases can be executed in parallel, independently of one another and without mutual dependence.

Phase 2: Backend Code Quality 🔒

Focus on backend (packages/service/、projects/app/src/pages/api/、projects/app/src/service/) quality issues, and complete the following checklist:

Phase 3: Frontend Code Quality 🎨

Focus on frontend (projects/app/src/、packages/web/) quality issues, and complete the following checklist:

Phase 4: Code Style Standards 📐

Check against each FastGPT standard one by one, and complete the following checklist:

[] i18n Static Key Standards: Check whether newly added/modified t(...) calls can be statically recognized by the i18n cleanup script. Prohibit t(`ns:key_${value}`)、t(prefix + value)、t(variableKey)、t(condition ? 'ns:a' : 'ns:b') dynamic or expression keys; finite enumerations must be split into explicit branches or static mappings, and the final call must remain in the t('ns:literal_key') form. At the same time, confirm that all referenced keys have been added to the corresponding language packs, to avoid being mistakenly cleaned up or displaying bare keys at runtime.
[] API Route Development Standards
[] Frontend Component Standards
[] Database Standards
[] Package Structure Standards
[] Logging Standards
[] Service Decoupling Standards
[] Syntax Style Standards

Phase 5: Test Coverage 🧪

Does the newly added core business logic have corresponding unit tests (test/ or projects/*/test/）？
Do the tests cover the normal path, boundary conditions, and error paths?
If there are no tests, assess the risk level of the missing tests (high-risk logic without tests should be marked as 🔴).

Phase 6: Regression Risk Detection 🔄

API Compatibility: Does the external API have breaking changes (field deletion, type change, behavior change)?
Database Compatibility: Is the schema change backward compatible? Does old data need migration?
Dependency Impact: Will the modified public modules (packages/global/、packages/service/) affect other callers?
Configuration Changes: Have any required configuration items been added without providing default values or migration instructions?

Final Step: Submit Review Report

Collect issues from all phases

Summarize the issues found in each phase and classify them by severity:

🔴 Critical(must be fixed before merging)
🟡 Recommended(improve code quality)
🟢 Optional(optimization suggestions)

Submit line-level code comments

GitHub CLI does not support line-level comments; they must be submitted via the GitHub API:

REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)

cat > /tmp/review-data.json << 'EOF'
{
  "body": "## 📊 代码审查总结\n\n详细意见请查看下方行级评论。",
  "event": "COMMENT",
  "comments": [
    {
      "path": "文件路径",
      "line": 行号,
      "body": "🔴 **问题描述**\n\n**建议**:\n```typescript\n// 修复示例\n```"
    }
  ]
}
EOF

gh api repos/$REPO/pulls/<number>/reviews \
  --method POST \
  --input /tmp/review-data.json

Review Report Template

# PR Review: {PR Title}

## 📋 需求理解
{第一阶段总结：PR 的核心目的与改动范围}

## 🧪 逻辑验证
{列出提出的测例及推理结果，标明是否通过}

## ⚠️ 问题汇总

### 🔴 严重问题（{count} 个，必须修复）
{问题列表，行级评论已标注}

### 🟡 建议改进（{count} 个）
{问题列表}

### 🟢 可选优化（{count} 个）
{问题列表}

## ✅ 做得好的地方
{列出值得肯定的实现}

## 🚀 审查结论
{通过 / 需修改 / 阻塞（说明原因）}

Command Reference

Scenario	Command
Request Changes	`gh pr review <number> --request-changes --body-file /tmp/review.md`
Approve PR	`gh pr review <number> --approve`
Comment Only	`gh pr review <number> --comment --body-file /tmp/review.md`