bright-room Code Review Skill
PR に対してコードレビューを実施し、指摘事項をインラインコメントとして GitHub 上に投稿する。コードベース全体レビューの場合はローカルファイルとして出力する。
レビュー方針
- 行番号と**文脈情報（背景知識など）**を必ず含める
- レビュー結果はチームメンバーに共有されるため、細部まで入念に確認すること
- 書き始める前に深く考察し、すべての箇所を漏れなくチェックすること
- 事実に基づかない内容（ハルシネーション）を含めないこと
前提条件
ghCLI が認証済みであること
レビューモードの解決ルール
引数に応じて、レビューモードを以下の優先順で決定する:
| 条件 | モード | レビュー対象 | 出力先 |
|---|---|---|---|
| PR 番号を指定（数値のみ） | PR レビュー | PR の差分 | GitHub インラインコメント |
--full-codebase 指定 |
コードベース全体レビュー | main ブランチの全コード | ローカルファイル |
PR 番号が指定された場合は必ず PR レビューモードとなる。
カテゴリ選択ルール
レビューするカテゴリを以下の優先順で決定する:
| 条件 | カテゴリ |
|---|---|
--full 指定 |
全6カテゴリ |
--category 指定 |
指定されたカテゴリのみ |
| コードベース全体レビュー | 全6カテゴリ |
| PR レビュー（カテゴリ指定なし） | 変更ファイルから自動選択（後述） |
変更ファイルからのカテゴリ自動選択（PR レビュー時のデフォルト）
変更されたファイルのパスに基づいて、レビューするカテゴリを自動で絞り込む。
.claude/skills/references/project-context.md の「ファイルパス → カテゴリマッピング」テーブルに従ってカテゴリを選択する。
- 1つのファイルが複数カテゴリにマッチする場合はすべて選択する
- プロダクトコードは PR レビュー時に常に含める（最低1カテゴリ）
使用可能なカテゴリ名
--category で指定可能な値（複数指定はカンマ区切り: --category security,code）:
| カテゴリ名 | 説明 |
|---|---|
architecture |
設計パターン、モジュール分割、依存関係の適切さ |
code |
ロジックの正確性、エッジケース、命名規則、コーディング規約への準拠 |
test |
テストカバレッジ、テストケースの網羅性、テストの品質 |
security |
認証・認可の実装、入力バリデーション、機密情報の取り扱い |
docs |
API ドキュメントの整備状況、README の更新、公開 API の説明 |
build |
ビルド設定、依存関係管理、CI 設定の正確性 |
手順
1. レビュー対象の特定
モード A: PR レビュー
引数に PR 番号が指定された場合。
1-1. PR 情報の取得
# PR のベースブランチと最新コミット SHA を取得
gh pr view <pr-number> --json baseRefName,headRefOid,headRefName
# PR で変更されたファイル一覧を取得
gh api 'repos/{owner}/{repo}/pulls/<pr-number>/files' --jq '.[].filename'
1-2. レビュー済み判定と差分取得
前回レビュー以降の変更分のみをレビュー対象にする。
# 過去のレビュー一覧を取得
gh api 'repos/{owner}/{repo}/pulls/<pr-number>/reviews'
- 自身（claude）の最新レビューの
commit_id（レビュー時点の HEAD SHA）を特定する - 自身のレビューが見つかった場合:
git diff <前回レビューSHA>..<現在のHEAD SHA>で新規変更分のみを差分として取得する - 自身のレビューが見つからない場合（初回レビュー）: ベースブランチからの全差分を対象とする
1-3. Resolved 済みスレッドの除外
GraphQL API で Resolved 済みのレビュースレッドを取得し、既に解決済みの指摘を再度行わないようにする。
gh api graphql -f query='
{
repository(owner: "{owner}", name: "{repo}") {
pullRequest(number: <pr-number>) {
reviewThreads(first: 100) {
nodes {
isResolved
comments(first: 10) {
nodes { body, path, line }
}
}
}
}
}
}'
isResolved: trueのスレッドに含まれる指摘は、同じ内容を再度指摘しない- bot コメント（CI 等）も除外する
モード B: コードベース全体レビュー（--full-codebase 指定）
- リポジトリ内のすべてのソースファイルを読み込む
- テストファイル、設定ファイル、ドキュメントも対象とする
- ビルド成果物ディレクトリ（
build/、dist/、node_modules/等）はレビュー対象外とする
2. カテゴリの決定
引数とモードに基づいて、レビューするカテゴリを決定する（「カテゴリ選択ルール」参照）。
3. コードの読解
レビュー対象のファイルをすべて読み込み、内容を深く理解する。対象ファイルだけでなく、関連するファイル（呼び出し元、インターフェース、設定ファイルなど）も確認すること。
4. レビューの実施
選択されたカテゴリについてのみレビューを行う。
.claude/skills/references/project-context.md の「カテゴリ別レビュー観点」セクションを参照し、プロジェクト固有のレビュー観点に基づいてレビューすること。project-context.md に記載がないカテゴリは、一般的なベストプラクティスに基づいてレビューする。
5. レビュー結果の出力
モード A: PR レビュー -- GitHub インラインコメントとして投稿
指摘事項を GitHub PR レビューとして1回の API コールで投稿する。
gh api 'repos/{owner}/{repo}/pulls/<pr-number>/reviews' \
--method POST \
--input /tmp/review-payload.json
レビューペイロードの構造:
{
"commit_id": "<PR の最新コミット SHA>",
"body": "<!-- claude:review -->\n<レビュー総括コメント>",
"event": "COMMENT",
"comments": [
{
"path": "path/to/file",
"line": 42,
"side": "RIGHT",
"body": "**[Critical]** <指摘内容>\n\n**背景**: <なぜ問題なのか>\n\n**修正案**:\n```\n// 修正コード\n```"
}
]
}
event の選択基準
| 条件 | event |
|---|---|
| Critical の指摘がある | REQUEST_CHANGES |
| High 以下の指摘のみ | COMMENT |
| 指摘なし | APPROVE |
総括コメントのフォーマット
<!-- claude:review -->
## Code Review 総括
> レビュー日: YYYY-MM-DD
> レビューカテゴリ: <選択されたカテゴリ一覧>
### 総合評価
| 観点 | 評価 |
|------|------|
| <カテゴリ名> | ⭐⭐⭐⭐☆ |
### 指摘サマリ
| # | 優先度 | カテゴリ | 概要 |
|---|--------|----------|------|
| 1 | 🔴 Critical | <カテゴリ> | <概要> |
| 2 | 🟠 High | <カテゴリ> | <概要> |
---
🤖 *Reviewed by Claude Code*
インラインコメントの記述ルール
- 各コメントの先頭に優先度バッジを付ける:
**[Critical]**,**[High]**,**[Medium]**,**[Low]** - 背景（なぜ問題なのか）を必ず含める
- 修正案がある場合はコード例を含める
commit_idにはgh pr view <pr-number> --json headRefOid --jq .headRefOidで取得した最新コミット SHA を指定すること（行番号のズレを防ぐため）
API エラー時のフォールバック
API 呼び出しが失敗した場合は、ローカルファイルにフォールバック出力する。
- 出力先:
.claude/outputs/reviews/REVIEW-PR-<pr-number>.md - ユーザーに API エラーが発生した旨を報告する
モード B: コードベース全体レビュー -- ローカルファイルとして出力
レビュー結果を .claude/outputs/reviews/ ディレクトリにファイルとして出力する。
- ディレクトリが存在しない場合は作成すること
- ファイル名:
REVIEW-main-YYYY-MM-DD.md
以下のフォーマットに従ってレビュー結果を生成する。選択されたカテゴリのセクションのみ出力する。
# Code Review: main
> レビュー日: YYYY-MM-DD
> レビューカテゴリ: <選択されたカテゴリ一覧>
## 総合評価
| 観点 | 評価 |
|------|------|
| <カテゴリ名> | ⭐⭐⭐⭐☆ |
---
## <カテゴリ名>レビュー
### 🔴 Critical
#### C-1: <問題のタイトル>
**問題点**
> 📍 [`path/to/file:42`](path/to/file#L42)
> ```
> // 該当コードの引用
> ```
**背景**
<!-- なぜこれが問題なのか、技術的な文脈情報 -->
**修正案**
```
// 修正後のコード例
```
---
### 🟠 High
### 🟡 Medium
### 🟢 Low
セキュリティチェックリスト（security カテゴリ選択時のみ出力）
.claude/skills/references/project-context.md の「セキュリティチェックリスト」テーブルを使用する。
テストカバレッジマトリクス（test カテゴリ選択時のみ出力）
.claude/skills/references/project-context.md の「テストカバレッジマトリクス」テンプレートを使用する。
指摘の記述ルール
- 推測ではなく、実際にコードを読んで確認した事実のみを記載すること
- 良い点（Good practices）があれば、総括コメントで簡潔に言及すること
- セキュリティレビューでは、推測による脆弱性指摘は行わず、コード上で確認できる事実のみを記載すること
- ドキュメントレビューでは、ドキュメントの「有無」だけでなく「内容の正確性」も確認すること
- Resolved 済みのスレッドと同じ内容の指摘は行わないこと