review-pr

ローカルレビュー

体系的なレビューを実施し、実行可能で検証済みのフィードバックのみを提示します。 このスキルは、ネイティブの PR レビューツールの汎用的な代替としてではなく、引き継ぎ前の明示的なローカル自己レビューのステップとして使用してください。 コーディングセッションで確認する価値のある変更が生じた場合は、/done の前に実行してください。

参照ファイル

ファイル	読み込むタイミング
references/severity-rubric.md	デフォルト：深刻度ラベルの選択と、根拠の弱い指摘の除外
references/comment-examples.md	ローカルレビュー報告を作成する前
references/review-surfaces.md	ローカル自己レビューを続けるか、PR 専用のワークフローに引き継ぐかを判断するとき
references/security-checklist.md	差分が認証、入力処理、外部 API、ファイルアップロード、または環境設定に関係するとき
references/performance-checklist.md	差分がデータ取得、レンダリング、画像、依存関係、またはバンドルに影響するインポートに関係するとき

対象範囲

• デフォルトの対象：ステージ済みまたは未コミットのローカル変更
• 二次的な対象：作業ツリーがクリーンな場合、またはユーザーがブランチレビューを依頼した場合の、現在のブランチとベースとの差分
• 明示的な PR の依頼は二次的な対象です。同じレビュー基準を適用しつつ、主なワークフローではなく引き継ぎ経路として扱います
• このスキルの対象は、具体的なバグ、明らかに重要な検証やテストの不足、リポジトリの指示ファイルへの準拠に限定してください
• 受信した PR コメントやスレッドの解決にはこのスキルを使用せず、その場合は pr-comments を使用してください

ワークフロー

進捗を追跡するため、このチェックリストをコピーしてください。

Review progress:
- [ ] Discover local review target
- [ ] Gather context and scoped instruction files
- [ ] Choose the local review path
- [ ] Validate findings
- [ ] Produce the review report

1. レビュー対象を特定する：
   • ステージ済みまたは未ステージの変更がある場合は、まずそれらをレビューします
   • それ以外の場合は、現在のブランチとベースとの差分をレビューします
   • ユーザーが既存の PR を明示的に指定した場合に限り、PR 引き継ぎ用の要約に切り替えます
   • 報告の根拠をローカルセッションに置くため、現在のブランチと変更ファイルを記録します
2. コンテキストを収集する：
   • セッション、最近のコミット、またはユーザーの依頼から変更の意図を把握します
   • 関連するリポジトリの指示ファイル（該当する AGENTS.md / CLAUDE.md を含み、差分内のコードがあるネストされたパッケージ／MFE ディレクトリ内のものも含む）を読み込みます
   • 変更されたパスに適用される指示ファイルのルールのみを適用します
   • プロジェクトの lint、型チェック、テストの各コマンド（package.json のスクリプトに記載）を実行して、現時点の状態を記録します。変更によるリグレッションと区別できるよう、変更前から存在する失敗を記録してください。レビュー時点のベースラインが分かるよう、lint／型チェック／テストの状態を報告に含めます
3. ローカルレビューの経路を選ぶ：
   • デフォルトはローカル自己レビューです。現在の差分／ブランチを対象に、チャットでローカル報告を作成します
   • 既存の PR の依頼は二次的な対象です。同じ検証基準を適用したうえで、主なワークフローを変更せず、簡潔な引き継ぎ用の要約を作成します
   • 大規模な変更はサブシステムごとに分割し、最終報告をまとめて提示します
4. 問題を検証する：
   • 報告する前に、該当する正確な行を再確認します
   • 確度の高い問題のみを残し、推測に基づく項目や重複する項目は除外します
   • 各問題が最新の差分にも当てはまり、変更行に該当することを確認します
   • 根本原因が同じ複数のコメントは、1つの指摘にまとめます
5. 報告を作成する：
   • デフォルトの出力：チャットでのローカルレビュー報告
   • 指摘は Must fix before push、Should fix soon、Ready for handoff に分類します
   • このスキルからインラインコメントの投稿、スレッドの解決、受信したレビューコメントへの対応は行いません
   • 受信した PR フィードバックは pr-comments に引き継ぎます

重要度の高い指摘のみ

確実な場合にのみ指摘してください。

• コードがコンパイルに失敗する（構文、型、インポート）
• コードが誤った動作をする（明確なロジックや状態の誤り）
• 具体的なセキュリティリスクを生み、直接的な悪用経路があるコード変更 — 差分が認証、入力処理、外部 API、環境設定に触れる場合は、3 段階の分類について references/security-checklist.md を読み込んでください
• 測定可能なパフォーマンス低下を引き起こすコード変更 — 差分がデータ取得、レンダリング、画像、依存関係に触れる場合は、一般的なボトルネックのパターンについて references/performance-checklist.md を読み込んでください
• 変更された動作に対し、必要なリグレッションテストや検証テストが明らかに欠けている。次のケースを含みます。新しいコンポーネントやフックに、同じ場所に配置されたテストファイルがない場合。または、既存のテストがすべてレンダリング時の存在確認のみのアサーション（expect(getByText(...)).toBeInTheDocument()）で、ユーザー操作や分岐のカバレッジがない場合
• 不具合修正に、最初に不具合を再現する失敗テストがない（Proof-It パターン：修正が正しければ、不具合のテストは修正前に失敗し、修正後に成功する必要があります）
• テストコードの共通セットアップが過度に抽象化され、ヘルパーをたどらないと個々のテストが読めない（テストコードでは DRY より DAMP — Descriptive And Meaningful Phrases — を優先してください）
• 変更が原因でリンター、型チェック、テストが失敗する（手順 2 で記録された既存の失敗と区別してください）
• 指示ファイルへの明白な違反（ルールを引用し、適用範囲を確認してください）
• YAGNI 違反：現在の要件では正当化できない抽象化、設定システム、拡張ポイントをコードが追加している（時期尚早な抽象化より、似た行が 3 行あるほうが適切です）
• KISS 違反：実装が問題に対して過度に複雑で、同じ結果を得られるより単純な方法がある

次のことは決して指摘しないでください。

• スタイル、品質、または主観的な好み
• 変更と無関係な既存の問題
• 不明な入力に依存する潜在的な問題
• 自動で検出される可能性が高い、リンターのみが検出する問題
• 明示的に無効化された違反

出力形式

レポートを作成する前に、書式を確認する必要があれば references/comment-examples.md を読んでください。

デフォルトのローカル出力：

## Local review

### Must fix before push
- [<severity>] `path/to/file.ts:line` <short factual title>
  Why: <one to two sentences with concrete impact>
  Fix: <committable fix or clear implementation guidance>

### Should fix soon
- [<severity>] `path/to/file.ts:line` <short factual title>
  Why: <one to two sentences with concrete impact>
  Fix: <committable fix or clear implementation guidance>

### Ready for handoff
- <brief readiness summary>

ユーザーが既存の PR を明示的に指定した場合は、同じ検証済みの指摘事項を簡潔な引き継ぎサマリーにまとめてください。

## PR handoff summary

- [<severity>] `path/to/file.ts:line` <short factual title>
  Why: <one to two sentences with concrete impact>
  Fix: <committable fix or clear implementation guidance>

サマリー（問題がない場合）：

## Local review

### Must fix before push
- None.

### Should fix soon
- None.

### Ready for handoff
- No blocking issues found. Checked for high-confidence bugs, missing validation/tests, and instruction-file compliance on the current local changes.

アンチパターン

• ローカルの変更が確認できるのに、最初に PR 番号を尋ねる → まずローカルの差分をレビューしてください
• インラインのレビューコメントをデフォルトの出力にする → 基本の流れではローカル優先を維持してください
• 「問題が起きるかもしれません」→「src/foo.ts:45 で変数 x が未定義のため、実行時に ReferenceError が発生します。」
• 「リファクタリングを検討してください」→「スコープ内のファイル src/foo.ts で、指示ファイルのルール『<引用したルール>』に違反しています。」
• 同じ根本原因に対して複数のコメントを付ける → 影響を受けるすべての場所を関連付けた 1 件のコメントにしてください

関連スキル

• レビュー完了後のセッション記録には done
• フィードバック後に受け取ったレビュー スレッドのトリアージと解決には babysit-pr

指摘事項はすべて、シニアエンジニアが見落とさないようなものである必要があります。