code-review

name	code-review
description	PRのコードレビューをAgentで別セッション実行し、low以下のみなら自動マージする（個人開発向け）

Code Review

$ARGUMENTS に PR番号または PR URL を受け取り、別セッションのAgentでレビューを実施してGitHubにコメントを投稿する。 low のみであれば自動マージまで行う。

ユーザーが /code-review <番号> で明示的に呼び出す。

テンプレート変数

使用前に以下を各プロジェクトに合わせて置換すること:

• {{REPO}} — GitHubリポジトリ（例: owner/repo）
• {{BUILD_COMMAND}} — ビルド確認コマンド（例: cd frontend && pnpm run build）

呼び出し方

/code-review 197
/code-review https://github.com/{{REPO}}/pull/197

Agent への委譲

以下のプロンプトで general-purpose Agent を バックグラウンドで 起動する。 PR番号は $ARGUMENTS から取り出すか、URLから抽出する。

以下の手順で PR <番号> のコードレビューを行い、GitHubにコメントを投稿してください。

## 手順

1. PR情報とdiffを取得する
   gh pr view <番号> --repo {{REPO}}
   gh pr diff <番号> --repo {{REPO}}

2. 下記「レビュー観点」に沿って分析し、各問題に重要度フラグを付ける

3. 問題点・良い点をまとめてGitHubにコメントを投稿する
   gh pr comment <番号> --repo {{REPO}} --body "<レビュー内容>"

4. ビルドが通ることを確認する

   変更が含まれる場合は必ずビルドを実行し、成功を確認する:

{{BUILD_COMMAND}}

ビルドが失敗した場合は **critical/high 件数に関わらず自動マージしない**。
ビルドエラーの内容をレビューコメントに追記する。

5. 重要度に応じて自動マージするか判断する

- ビルドが失敗している場合:
  コメントのみ投稿する。マージはしない。

- critical / high / medium が1件以上ある場合:
  コメントのみ投稿する。マージはしない。

- low のみ、または問題なし の場合（かつビルド成功）:
  gh pr merge <番号> --repo {{REPO}} --auto
  （注意: --squash / --rebase は付けない。マージコミットをそのまま使う）

6. PRがマージされるまで待機する

自動マージ・手動マージどちらの場合も対応するため、以下のループでマージを検知する:
- 30秒ごとに `gh pr view <番号> --repo {{REPO}} --json mergedAt --jq .mergedAt` を実行
- 空文字列でなければマージ済みと判定
- 最大60回（約30分）試行する
- 30分経過してもマージされなければタイムアウトとして終了する

**重要: `git checkout` や `git pull` などローカルのブランチを切り替えるコマンドは絶対に実行しないこと。**
バックグラウンドAgentがこれらを実行すると、メインの作業ディレクトリのファイルが上書きされ、
ユーザーの作業中のブランチが破壊される。ローカル追従はユーザー自身が行う。

## 重要度フラグ

各問題に以下のいずれかのフラグを付けて分類する:

- [critical] セキュリティ脆弱性、データ破壊・消失の可能性、本番障害に直結するバグ
- [high]     バグになりうる、データ不整合、エラーハンドリングの欠落
- [medium]   パフォーマンス問題（N+1クエリ、大量メモリ使用）、API互換性の懸念
- [low]      可読性、慣習、軽微なリファクタリング提案、nit

## レビュー観点

### 1. エラーハンドリング

HTTPステータスコードの意味的な正しさを確認する:
- 401 Unauthorized → 認証されていない（トークン不正・未提供）
- 403 Forbidden → 認証済みだが権限不足
- 404 Not Found → リソースが存在しない
- 500 Internal Server Error → サーバー側の予期しないエラー

よくある誤り:
- ユーザーが見つからない → 401 ではなく 404 or 500（文脈による）→ [high]
- バリデーションエラー → 500 ではなく 400 → [high]

エラーの種類をまとめてキャッチしていないか:

// 悪い例: 異なるエラーを同じ処理にまとめている → [medium] // DBエラーとNot Foundを混在させない

### 2. フォールバック動作とUX

データが欠損・削除済みの場合にクライアント側でどう見えるかを確認する。
- IDがそのままユーザー名として表示される → [medium]
- エラー時にスタックトレースが露出する → [high]

### 3. マイグレーションの品質（マイグレーションが含まれる場合）

- べき等性がない（2回実行で壊れる）→ [high]
- 大量データを一度にメモリ読み込み → [medium]
- 個別更新をN回発行（bulk操作で改善可能）→ [medium]
- ロールバック手段がない → [low]

### 4. N+1クエリ / バッチ処理

- ループ内でDBアクセスが発生している → [medium]
- 重複排除なしのバッチ取得 → [low]

### 5. API後方互換性

- フィールドの削除・リネームでクライアント側が壊れる → [high]
- 内部ストレージの変更がAPIレスポンスに露出している → [medium]

### 6. コード品質

- パニック・例外の可能性がある安全でない操作 → [high] or [medium]（文脈による）
- 不必要なコピー・クローン → [low]
- エラーや不正値のサイレント無視 → [medium]

## コメントのフォーマット

以下の形式でコメントを投稿する:

## レビューサマリー

| 重要度 | 件数 |
|--------|------|
| critical | N |
| high | N |
| medium | N |
| low | N |

**判定:** critical/high/medium/low のみ / 問題なし
（例: "low のみのため自動マージします" または "medium が含まれるためマージを保留します"）

**変更の概要:** PRの変更内容を2〜3文で要約する。どのような問題を解決しどう実装したかを記述。

---

## 詳細

### [critical/high/medium/low] タイトル

ファイルパス（わかれば行番号も）

問題の説明と理由。

**修正案:** （あれば）

---

### 良い点

- ...

問題点がなければ「問題なし、自動マージします」と明記する。

注意

• Agent はバックグラウンド実行（run_in_background: true）で起動し、完了通知を受け取る
• /code-review <番号> でユーザーが明示的に呼び出す
• Agent内で git checkout / git pull / git switch など、ローカルブランチを切り替えるコマンドは禁止。メインの作業ディレクトリを破壊するため。