pr-review

PR レビュー

最近の PR を取得して分類し、ソースコードを読み、コンテキストに沿ったレビューを作成します。

入力

$ARGUMENTS — PR の件数（デフォルト：10）

例：

• /pr-review — 最新のオープン PR を10件
• /pr-review 20 — PR を20件

ワークフロー

1. 最近の PR を取得

gh pr list --repo toss/es-toolkit --state open --limit {count} --json number,title,author,labels,createdAt

2. 各 PR をトリアージ

各 PR を分類するため、/pr-triage {number} を実行します。

3. PR ごとの詳細レビュー

各 PR について、分類だけでなく、実際のソースコードを読み、状況を踏まえてレビューします。

a. 現在のコードを読む

現在の動作を理解するため、main ブランチで変更対象のファイルを読みます。

• 関数のソース：何をするのか、どのように動作するのか
• 既存のテスト：すでに何がカバーされているのか
• JSDoc：文書化されている動作と例

b. PR の変更内容を理解する

何が変更されるのかを理解するため、差分を読みます。

• 変更前と変更後の違いは何か
• コントリビューターは、なぜこの変更が必要だと述べているのか
• この変更は、コードが実際に必要としているものと一致しているか

c. 影響を評価

• 破壊的変更：関数シグネチャは変更されるか。既存ユーザーに影響するか
• JS 仕様との整合性：現在の動作は JS／lodash の慣例に従っているか。PR によってそれが損なわれないか
• 範囲：影響を受けるすべてのファイルが更新されているか（例：4言語すべてのドキュメント、関連する関数）
• 設計原則：es-toolkit の「ユースケースの85％をカバーする」／シンプルさを重視する方針に沿っているか

d. ラベルごとの確認項目

• compat-fix：/compat-review {number} を実行
• new-function：完全性を確認（実装 + 仕様 + 再エクスポート + 4言語のドキュメント）
• core-change：yarn vitest run src/{category}/{fn}.spec.ts を実行し、破壊的な影響をレビュー
• docs：4言語すべてのファイルが一貫して更新されているか確認
• types：tsc --noEmit を実行

4. 重複を検出

同じ関数名、または同じファイルを変更している PR をグループ化します。

5. PR ごとのレポート

各 PR について、次の内容を出力します。

### PR #{number} — {title}

**Classification**: {labels}
**Changed files**: {summary}

**Current code**: {what the function does now, with code snippet}
**PR change**: {what's changing and why, with before/after}
**Context**: {JS spec, lodash behavior, design principle considerations}

**Checkpoints**:
- {specific things to verify}

**Verdict**: {merge / merge with changes / hold for discussion / reject}

6. まとめ

## PR Review — {date}

| # | Title | Label | Verdict |
|---|-------|-------|---------|

- {N} ready to merge
- {N} need changes
- {N} need discussion
- {N} potential duplicates