github-pr-review

GitHub PR 审查

概述

使用 gh api 审查 GitHub 拉取请求并创建包含代码建议的待处理审查的工作流。即使时间紧迫，也始终使用待处理审查来批量提交评论。

**重要：发布任何审查评论前，务必先获得用户的明确批准。**准确展示将要发布的内容，并使用 AskUserQuestion 询问用户是否同意。

适用场景

• 审查拉取请求
• 为 PR 添加代码建议
• 使用 gh CLI 发布审查评论

前提条件

重要：尝试使用此技能前，请检查是否已安装 gh CLI。

检查 gh CLI

开始任何 PR 审查工作流前，确认 gh CLI 可用：

gh --version

如果未安装 gh：

1. 立即停止——不要尝试运行 gh api 命令
2. 向用户发送以下消息：

The GitHub CLI (gh) is required for this skill but is not installed.

Please install it from: https://cli.github.com/

Installation options:
- macOS: brew install gh
- Windows: winget install GitHub.cli
- Linux: See https://cli.github.com/ for your distro

After installing, authenticate with:
  gh auth login

Then try your PR review request again.

3. 在安装 gh 前不要继续审查工作流

安装后

安装 gh 后，用户必须进行身份验证：

gh auth login

核心工作流

必需步骤（不得跳过）：

1. 检查是否已安装 gh CLI——运行 gh --version 进行确认
2. 起草审查内容——分析 PR 并准备所有评论
3. 准确展示将要发布的内容——使用 AskUserQuestion 询问用户是否同意
4. 获得明确批准——等待用户确认
5. 发布审查——仅在获得批准后进行

批准流程

发布任何审查前，使用 AskUserQuestion 展示：

• 每条评论对应的文件和行号
• 评论的完整文本（包括代码建议）
• 事件类型（APPROVE/REQUEST_CHANGES/COMMENT）
• 总体审查消息

示例：

Question: "Ready to post this review?"
Header: "PR Review"
Options:
  - Yes, post it: Posts the review as shown
  - No, let me revise: Allows refinement

技术工作流

始终使用待处理审查模式，即使只有一条评论也如此：

# Step 1: Create PENDING review (no event field)
gh api repos/:owner/:repo/pulls/<PR_NUMBER>/reviews \
  -X POST \
  -f commit_id="<COMMIT_SHA>" \
  -f 'comments[][path]=path/to/file.ts' \
  -F 'comments[][line]=<LINE_NUMBER>' \
  -f 'comments[][side]=RIGHT' \
  -f 'comments[][body]=Comment text

```suggestion
// suggested code here

其他说明……'
--jq '{id, state}'

返回：{"id": <REVIEW_ID>, "state": "PENDING"}

第 2 步：提交待处理审查

gh api repos/:owner/:repo/pulls/<PR_NUMBER>/reviews/<REVIEW_ID>/events
-X POST
-f event="COMMENT"
-f body="可选的总体审查消息"

## Event Types

Choose the appropriate event type when submitting:

| Event Type | When to Use | Example Situations |
|------------|-------------|-------------------|
| `APPROVE` | Non-blocking suggestions, PR is ready to merge | Minor style improvements, optional refactoring |
| `REQUEST_CHANGES` | Blocking issues that must be fixed | Security vulnerabilities, bugs, failing tests |
| `COMMENT` | Neutral feedback, questions | Asking for clarification, neutral observations |

## Quick Reference

### Getting Prerequisites

```bash
# Get commit SHA
gh pr view <PR_NUMBER> --json commits --jq '.commits[-1].oid'

# Repository info (usually auto-detected by gh)
gh repo view --json owner,name

必需参数

• commit_id：PR 的最新提交 SHA
• comments[][path]：相对于仓库根目录的文件路径
• comments[][line]：结束行号（数字使用 -F）
• comments[][side]：新增或修改的行使用 RIGHT（最常见），删除的行使用 LEFT
• comments[][body]：评论文本，可选择包含 ```suggestion 代码块

可选参数

• comments[][start_line]：用于多行代码建议（使用 -F）
• event：留空表示 PENDING，或使用 COMMENT/APPROVE/REQUEST_CHANGES

语法规则

✅ 应当：

• 对包含 [] 的参数使用单引号：'comments[][path]'
• 字符串值使用 -f
• 数字值（行号）使用 -F
• 代码建议使用带有 suggestion 标识符的三个反引号

❌ 不要：

• 对 comments[][] 参数使用双引号
• 混淆 -f 和 -F 标志
• 忘记先获取提交 SHA

代码建议格式

-f 'comments[][body]=Your comment explaining the issue

```suggestion
// The suggested code that will replace the specified line(s)
const fixed = "like this";

建议之后的其他背景信息或说明。'

**Important**: Code suggestions replace the entire line or line range. Make sure the suggested code is complete and correct.

### Edge Case: Suggestions with Nested Code Blocks

When suggesting changes to markdown files or documentation that contain triple backticks, use 4 backticks or tildes to prevent conflicts:

`````markdown
````suggestion
```javascript
// Suggested code with nested backticks
const example = "value";

也可以使用波浪号：

~~~suggestion
```javascript
const example = "value";

```

## Common Mistakes

| Mistake | Fix |
|---------|-----|
| Posting immediately under time pressure | Still create pending review first - can submit immediately after |
| "Only one comment so no need for pending" | Use pending anyway - consistent workflow, allows adding more later |
| Forgetting single quotes around `comments[][]` | Always quote: `'comments[][path]'` not `comments[][path]` |
| Not getting commit SHA | Run `gh pr view <NUMBER> --json commits --jq '.commits[-1].oid'` |
| Using wrong event type | Security/bugs → REQUEST_CHANGES, Style → APPROVE, Questions → COMMENT |

## Red Flags - You're About to Violate the Pattern

Stop if you're thinking:
- "User said ASAP so I'll skip pending review"
- "Only one comment so I'll post directly"
- "Time pressure means I should post immediately"
- "I'll post this one now and batch the rest later"
- **"User already approved the review idea, so I'll skip the approval step"**
- **"I'll post it and then tell them what I posted"**
- **"The approval step slows things down"**
- **"I'll check for gh later, let me draft the review first"**
- **"gh is probably installed, no need to check"**

**All of these mean: STOP. Check gh first, get explicit approval, then use pending review.**

**Why pending reviews?** Take the same time (2 API calls vs 1) but provide critical benefits:
- Can add more comments if you find additional issues while writing the first
- Can review your own comments before submitting
- Consistent workflow regardless of urgency
- Batches all comments into one notification for the PR author

**Why approval step?** Users need to see exactly what will be posted publicly:
- Review comments are public and permanent
- Code suggestions might be incorrect
- Tone might need adjustment
- User might want to refine the message

## Complete Example with Approval

**Step 1: Draft and show for approval**

First, analyze the PR and draft your comments. Then use AskUserQuestion:

```
I've reviewed PR #123 and found 3 issues. Here's what I'll post:

**Comment 1:** src/auth.ts line 20
Token expiry validation is missing...
[code suggestion shown]

**Comment 2:** src/auth.ts line 35
Missing error handling...
[code suggestion shown]

**Comment 3:** tests/auth.test.ts line 12
Missing error case test...
[code suggestion shown]

**Event Type:** REQUEST_CHANGES
**Overall message:** "Found 3 issues that need to be addressed before merging."

Ready to post this review?
```

**Step 2: After approval, post the review**

```bash
# Create pending review with multiple comments
gh api repos/:owner/:repo/pulls/123/reviews \
  -X POST \
  -f commit_id="abc123" \
  -f 'comments[][path]=src/auth.ts' \
  -F 'comments[][line]=20' \
  -f 'comments[][side]=RIGHT' \
  -f 'comments[][body]=First issue...' \
  -f 'comments[][path]=src/auth.ts' \
  -F 'comments[][line]=35' \
  -f 'comments[][side]=RIGHT' \
  -f 'comments[][body]=Second issue...' \
  -f 'comments[][path]=tests/auth.test.ts' \
  -F 'comments[][line]=12' \
  -f 'comments[][side]=RIGHT' \
  -f 'comments[][body]=Third issue...' \
  --jq '{id, state}'

# Submit with appropriate event type
gh api repos/:owner/:repo/pulls/123/reviews/<REVIEW_ID>/events \
  -X POST \
  -f event="REQUEST_CHANGES" \
  -f body="Found 3 issues that need to be addressed before merging."
```

## Real-World Impact

**Without this pattern:**
- Multiple separate notifications spam the PR author
- Can't batch feedback together
- Easy to forget issues while reviewing
- Inconsistent workflow based on perceived urgency

**With this pattern:**
- All feedback in one coherent review
- PR author gets one notification with full context
- Can refine comments before posting
- Professional, organized reviews