review-pr

プルリクエストをレビューする

目的

外部のプルリクエスト（GitHub）またはマージリクエスト（GitLab）の詳細を取得し、CI のステータスを確認して、変更されたコードに検証スキルを実行します。統合レポートを生成します。これは読み取り専用の操作です。プルリクエストへのプッシュやコメント、コードの変更は決して行いません。

入力

必須：$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 — 変更された画面や機能の UX レビュー
• exerciser — 手動の E2E テスト

各スキルのプロンプトに使用するスコープコンテキストのテンプレート：

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 と同じエージェント呼び出しパターンを使用します。エージェントごとの詳細なプロンプトテンプレートについては、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?]

Issue ID には RI-{n} の接頭辞（Review Issue）を使用し、/verify の VI-{n} 接頭辞と区別します。

10. レポートを提示して停止する

完全なレポートをユーザーに提示し、停止します。

次のことは行わないでください。

• 問題を自動修正する
• PR にコメントする
• PR を承認または却下する
• 対話形式のトリアージを開始する
• /verify の再実行を提案する

次に何をするかはユーザーが決定します。

Issue の重複排除

/verify と同じ方法を使用します。

1. 各スキルのすべての指摘を収集する
2. 重複（同じファイル／場所、同じ根本原因、異なる観点から見た同じ症状）を特定する
3. すべての報告元エージェントを記載し、最も高い重大度を適用して、単一の Issue にまとめる
4. RI-{n} ID を連番で割り当てる
5. 重大度の降順で並べ替える