code-review

コードレビューを行う。$ARGUMENTS は PR 番号（123、#123）、URL、または空。

差分の取得

まず $ARGUMENTS と現在の状態からレビュー対象を判定する。

• PR 番号・URL が指定された場合: gh pr view で PR 情報を取得し、gh pr diff で差分を取得する
• $ARGUMENTS が空の場合: gh pr view を試み、現在のブランチに PR が存在するか確認する
  • PR が存在する → PR モードで差分を取得
  • PR が存在しない → git diff main...HEAD でメインブランチとの差分を取得（ローカルモード）

情報収集

1. PR モードの場合、PR の情報（タイトル、説明、関連 issue）を把握する
2. ローカルモードの場合、ユーザーに関連する issue 番号を質問する（なければスキップ可）
3. 関連する issue がある場合は gh issue view で issue の目的・要件を把握する
4. ローカルモードの場合、tmp/issues/<issue番号>/ 配下の既存成果物を確認する。存在するファイルはレビューの参考情報として活用する
   • plan.md — 実装計画。意図した設計や変更方針との整合性を確認する
   • report.md — 実装レポート。実装者が認識している懸念点や追加変更を把握する
   • checklist.md — 受け入れテストチェックリスト。テストの網羅性を検証する際の基準にする
   • pr.md — PR テキスト。PR の説明と実際の差分に乖離がないか確認する

レビュー

5. 差分の規模を確認し、変更ファイルごとにコードベースの該当箇所を読み、変更のコンテキストを理解する
6. 以下の観点でレビューを行う:
   • 正確性: ロジックにバグや抜け漏れがないか
   • 設計: 責務分離、命名、既存パターンとの一貫性
   • セキュリティ: インジェクション、認証・認可の不備、機密情報の漏洩がないか
   • パフォーマンス: N+1 クエリ、不要な再レンダリング、計算量の問題がないか
   • テスト: テストの網羅性、境界値・異常系のカバレッジ
   • 可読性: 複雑すぎるロジック、不明瞭な命名、過剰な抽象化がないか
7. 結果をテキスト出力でユーザーに報告する（フォーマットは sample.md を参照）

注意事項

• 軽微なスタイルの指摘（空白、改行など）はリンターに任せ、レビューでは扱わない
• 指摘には必ず該当ファイルと行番号を含める
• 指摘ごとに重要度（must / should / nit）を付与する
• 良い点も積極的にコメントする