xs-code-reviewer

プルリクエストコードレビュー

GitHub CLIを使用してプルリクエストを分析し、バグ・リスク・回帰・不足テストを優先してレビューする。

重要: デフォルトはチャット上でのレビュー報告。GitHubへのコメント投稿、review投稿、approve/request changes は外部状態変更なので、ユーザーの明示OKを取ってから行う。

使用方法

PR#123をレビューして
owner/repo の PR#123 をレビューして
このPRを複数AIで見て

レビュー完了の定義

通常レビュー:

1. PR情報と差分を確認した
2. 必要に応じて xs-multi-agent で外部AIにも見せた
3. findings を重要度順に統合した
4. チャットでレビュー結果を報告した

GitHub投稿まで依頼された場合:

1. 投稿対象（repo / PR / コメント種別）を明示してユーザーのOKを取った
2. GitHubに投稿した
3. 投稿URLまたはPR URLを報告した

レビュー手順

Step 1: PR情報の確認

# PRテンプレートがあれば確認
test -f .github/pull_request_template.md && cat .github/pull_request_template.md

# PR詳細
gh pr view <PR番号> --repo <owner>/<repo> --json title,body,headRefOid,baseRefName,headRefName,files,additions,deletions,url

# 差分
gh pr diff <PR番号> --repo <owner>/<repo>

# 変更ファイル一覧
gh pr diff <PR番号> --repo <owner>/<repo> --name-only

--repo <owner>/<repo> を明示する。remote が複数ある環境では、gh が別リポジトリを選ぶ事故が起きやすい。

Step 2: ファイル別詳細分析

各変更ファイルについて必要に応じて確認する。

gh pr diff <PR番号> --repo <owner>/<repo> -- <ファイルパス>

ローカルにブランチを取得する場合は、既存未コミット変更を確認してから行う。

Step 3: レビュー観点

優先順位:

1. セキュリティ、データ損失、権限、公開範囲の問題
2. バグ、回帰、エラーハンドリング不足
3. テスト不足、検証不足
4. 仕様・ドキュメントとの不整合
5. 保守性、可読性、設計上の懸念
6. 好みの問題や軽微なスタイル

コードレビューでは、良い点より先に findings を出す。問題がない場合は「ブロッカーなし」と明示し、残るリスクや未検証項目を書く。

Step 4: マルチエージェント検証

複数AIで見る依頼、重要PR、大きめの差分では xs-multi-agent を併用する。

CONFIG_PATH="$(bash skills/xs-multi-agent/scripts/check_agents.sh)"
cat "$CONFIG_PATH"

依頼プロンプトはファイルに保存してから、利用可能な外部エージェントへ渡す。

cat > /tmp/pr-review-prompt.txt <<'EOF'
以下のPR差分をレビューしてください。
バグ、セキュリティ、回帰、不足テストを優先し、好みの指摘は後回しにしてください。

<PR情報と差分>
EOF

bash skills/xs-multi-agent/scripts/run_agent.sh codex /tmp/pr-review-prompt.txt "$PWD"

外部AIが使えない場合は、自分だけでレビューしてよい。その場合は「外部AIは検出したが使用できなかった」と報告する。

Step 5: 結果統合

複数AIの意見はそのまま並べず、重複をまとめて重要度順に統合する。

重要度:

• blocker: セキュリティ、データ損失、明確なバグ、重大な回帰
• major: 修正した方がよい設計・仕様・テスト不足
• minor: 軽微な改善
• nit: 好みや表記揺れ。必要な時だけ

誤検出の可能性がある指摘は、必ず差分やファイルを再確認してから出す。

出力フォーマット