review-pr

审查拉取请求

目标

通过获取详细信息、检查 CI 状态，并对变更的代码运行验证技能，审查外部拉取请求（GitHub）或合并请求（GitLab）。生成一份综合报告。这是一个只读操作——绝不推送、更不能在 PR 上发表评论或修改代码。

输入

必填：$ARGUMENTS — PR/MR URL。

支持的格式：

• GitHub：https://github.com/{owner}/{repo}/pull/{number}
• GitLab：https://gitlab.com/{owner}/{repo}/-/merge_requests/{number}

选项：

• --with-ux：同时运行 ux-reviewer 和 exerciser（默认跳过）

如果未提供 URL，则显示：

Usage: /review-pr <PR URL>
Example: /review-pr https://github.com/acme/api/pull/42

流程

1. 解析 PR URL

从 URL 中提取：

• 平台：github.com → GitHub，gitlab.com（或其他）→ GitLab
• Owner/Repo：例如 acme/api
• PR 编号：例如 42

如果 URL 与任一格式都不匹配，则报错并给出用法示例。

2. 验证本地仓库

此命令必须在正确的仓库克隆目录中运行。

# Confirm we're in a git repo
git rev-parse --git-dir

# Get local remote URL
REMOTE_URL=$(git remote get-url origin)

从 REMOTE_URL 提取 owner/repo（同时处理 SSH 和 HTTPS 格式）：

• HTTPS：https://github.com/acme/api.git → acme/api
• SSH：[email protected]:acme/api.git → acme/api

与 PR URL 中的 owner/repo 比较（忽略大小写，并移除 .git 后缀）。

如果不匹配，则立即停止并显示：

ERROR: Wrong repository.

This PR belongs to: {pr-owner}/{pr-repo}
You are currently in: {local-owner}/{local-repo}

To review this PR, first navigate to your local clone of {pr-owner}/{pr-repo}, then run:
  /review-pr {original URL}

3. 验证 CLI 工具

GitHub：

which gh && gh auth status

GitLab：

which glab && glab auth status

如果未安装 CLI 或未完成身份验证，则显示安装／身份验证说明并停止。

4. 获取 PR 元数据

GitHub：

gh pr view {number} --json title,body,author,baseRefName,headRefName,state,labels,additions,deletions,changedFiles,url

GitLab：

glab mr view {number}

继续之前，向用户简要展示 PR 摘要。

5. 检出 PR 分支

GitHub：

gh pr checkout {number}

GitLab：

glab mr checkout {number}

这样可确保所有代码都已在本地提供，供验证技能使用。

6. 获取变更文件和差异

GitHub：

# File list (scope for agents)
gh pr diff {number} --name-only

# Full diff (for scope line ranges)
gh pr diff {number}

GitLab：

glab mr diff {number}

解析差异，构建包含文件路径和变更行范围的范围列表。

7. 检查 CI 状态

GitHub：

gh pr checks {number}

GitLab：

glab ci status

记录每项检查／任务的状态（通过／失败／待处理／运行中）。不要等待待处理的检查——报告当前状态。

8. 启动验证技能

使用 Skill 工具并行调用技能。每个技能提示词都必须包含 PR 范围上下文。

要调用的技能：

• reviewer — 针对 PR 差异进行全面审查（设计、架构、一致性、强化、安全性）
• tester — 在了解范围的情况下运行测试套件

如果存在 --with-ux 标志，还要调用：

• ux-reviewer — 审查变更界面的用户体验
• exerciser — 手动端到端测试

每个技能提示词的范围上下文模板：

VERIFICATION SCOPE (PR #{number}: {title}):
Files in scope:
- {file1} (modified, lines X-Y, A-B)
- {file2} (added, entire file)
- {file3} (deleted)

CRITICAL SCOPE CONSTRAINTS:
- ONLY flag issues in code that was ADDED or MODIFIED in the PR diff
- DO NOT flag issues in surrounding context or old code unless it blocks the new changes
- DO NOT flag issues in files not listed in scope
- Focus exclusively on the quality of the NEW or CHANGED code

Exception: You MAY flag issues in old code IF:
1. The new changes directly interact with or depend on that old code
2. The old code issue causes the new code to be incorrect
3. The old code issue creates a blocker for the new functionality

[Skill-specific instructions follow...]

使用与 /verify 相同的 Agent 调用模式——各 Agent 的详细提示词模板请参阅 skills/quality/verify/SKILL.md。

9. 生成综合报告

将所有信息合并为一份报告：

# PR Review Report

## PR Overview

| Field | Value |
|-------|-------|
| Title | {title} |
| Author | {author} |
| Branch | {head} → {base} |
| Changes | +{additions} / -{deletions} across {changedFiles} files |
| URL | {url} |

**Description:** {first ~200 chars of body, or "No description provided"}

---

## CI Status

| Check | Status | Details |
|-------|--------|---------|
| {check1} | PASS/FAIL/PENDING | {duration or error} |
| {check2} | PASS/FAIL/PENDING | {duration or error} |

**Overall:** {N} passed, {N} failed, {N} pending

---

## Agent Results Summary

| Skill | Status | Notes |
|-------|--------|-------|
| tester | X passed, Y failed | [brief note] |
| reviewer | Completed | Found N items (design, arch, coherence, hardening, security) |
| ux-reviewer | Completed / Skipped | [if --with-ux] |
| exerciser | PASSED / FAILED / Skipped | [if --with-ux] |

---

## Issues Found

[Deduplicated issues from all agents, sorted by severity descending]

| ID | Sev | Title | Sources | Location | Description |
|----|-----|-------|---------|----------|-------------|
| RI-1 | 9 | [Title] | tester, reviewer | file:line | [Combined description] |
| RI-2 | 7 | [Title] | security | file:line | [Description] |

*Severity: 9-10 Critical | 7-8 High | 5-6 Moderate | 3-4 Low | 1-2 Trivial*

**Total: N issues from M skill findings (deduplicated)**

---

## Verdict

[One-paragraph overall assessment: is this PR ready to merge, or what needs attention?]

问题 ID 使用 RI-{n} 前缀（Review Issue），以区别于 /verify 的 VI-{n} 前缀。

10. 展示报告并停止

向用户展示完整报告，然后停止。

不要：

• 自动修复任何问题
• 在 PR 上发表评论
• 批准或拒绝 PR
• 开始交互式分类处理
• 建议再次运行 /verify

由用户决定下一步操作。

问题去重

采用与 /verify 相同的方法：

1. 收集各技能的所有发现
2. 识别重复项（文件／位置相同、根本原因相同，或不同角度描述的同一症状）
3. 合并为单个问题，列出所有来源 Agent，并采用最高严重性
4. 按顺序分配 RI-{n} ID
5. 按严重性降序排序