review-brief について
review-briefは、コード変更を簡潔でリスク重視のレビュー概要にまとめるスキルです。コーディングエージェント向けに、重要なコードやその他の変更、判断、状態、再現手順を示す構成を定めています。
主な機能
- 01差分の確認と不変条件の要約
- 02リスクに基づく変更分類
- 03重要コードと失敗時の影響の提示
- 04変更点と状態の表形式整理
- 05レビューと検証の指針
活用シーン
- 01レビュー担当者向けのPR要約
- 02スキーマ、セキュリティ、DB変更の強調
- 03変更状況と再現コマンドの確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/review-briefを入力して読み込まれたか確認します。
詳細
レビュー概要
読者は差分を読みません。30 秒ほどざっと目を通し、その後、問題を引き起こしかねないコードだけを読みます。その前提で最適化してください。
プロセス
- 差分を取得し（
git log --oneline main..HEAD、git diff --stat main..HEAD）、変更された重要なファイルをすべて最初から最後まで読みます。 - 不変の中核を見つけます。何が壊れていて、今は何が正しいのかを一文で述べます。
- すべての差分を分類します。以下の重要基準に該当するものは、コード欄にそのまま載せます。それ以外は表の 1 行にまとめるか、統合します。
- 以下のレイアウトで概要を書きます。記載するすべての行番号が、作業ツリーと一致していることを確認します。
- CODE のレビュアーとして、別のエージェントを実行します。文章ではなくコードについて、「何が誤っているか、誇張されているか、抜けているか」を確認させます。実際のバグは修正し、修正したことを明記します。
重要なコードの基準
次のいずれかに触れる差分は重要であり、コードとして示す必要があります。
- スキーマ。 Drizzle のテーブル、カラム、インデックス、マイグレーション、信頼境界にある Zod スキーマ、MCP ツールの入力または出力スキーマ。
- データベースへの書き込み。 新規または変更された INSERT／UPDATE／DELETE、条件付き WHERE 句、ワークフローステップや cron 内で実行される処理。
- セキュリティ。 認証チェック、スコープ／組織／プロジェクトのゲーティング、シークレット、認証情報を伴う外部呼び出し、フェイルオープンする処理。
- コアロジック。 バグに関係する結果を決める分岐や式：ステータスの設定、検証ゲート、ランキング比較、リトライまたはタイムアウトのポリシー。
- 不格好な実装。 レビューで説明するのが気まずいもの。UI 文言を決めるためのベンダーエラーメッセージの文字列照合、パーサーの代わりに使う正規表現、ハードコードされた参照テーブル、メトリクスがふさわしい場所での
console.warn、握りつぶされた catch、マジックなタイムアウト、パラメーター不足を補うために追加された DB 読み取り、動作をひそかに変えるフォールバックなどです。コードを示し、直前の文で不格好な実装だと明記し、現時点で許容できるのか、ブロッカーにすべきなのかを述べます。
各項目は 5～20 行で、判断に必要な箇所に絞ります。直前に注目点を一文で示し、直後に誤っていた場合の障害モードを一行で記します。抜粋は 3～6 個が標準です。6 個を超える場合は、PR を分割すべきでしょう。その旨を記載してください。
レイアウト
何が壊れていて、今は何が正しいのかを述べる一文。
変更前／変更後の図。 ユーザーに見える経路を示す ASCII フロー図を 2 列で作成します。ボックスはステップ、矢印は流れるものを表し、バグの箇所にはラベルを付けます。
重要なコード。 重要な抜粋をリスクの高い順に並べます。このセクションが概要の要です。後回しにしないでください。
その他すべてを 1 つの表にまとめる。 リスク順に並べます。
| # | ファイル | 内容 | 確認すべき点 |
|---|
意味のある変更ごとに 1 行を割り当てます。登録、名前変更、整形、フィクスチャは最後の 1 行にまとめます。
存在しないもの。 追加されたと読者が思い込む可能性があるものの、実際には追加されていない項目を箇条書きにします。例：マイグレーションなし、新しい依存関係なし、永続化される形状の変更なし、新しい認証経路なし。
異論がありそうな判断。 箇条書きを 2～4 個記載します。それぞれに、選択した方法、代替案、選択によるコストを含めます。選択を擁護する文章は一文を超えないようにします。
ステータス表。 マージ可否を判断する数値を記載します。例：テスト、ドライラン件数、「本番環境への適用：なし」。
2 分で試す。 変更を実行できるコマンドを 2～3 個記載します。
ブランチの状態。 コミット、プッシュ済みかどうか、PR のリンクまたは「PR はまだありません」。
ルール
- どの段落も 2 文を超えてはいけません。
- すべての箇条書きは、冒頭の数語を太字にして、流し読みしやすくします。
- 3 つ以上の並列項目には表を使います。
- コードは必ずコードフェンス内に記載し、文章中に書かないでください。読者がそのファイルを開く必要がある場合に限り、ファイル名を記載します。
- 求められていない限り、経緯、却下した案、マイグレーションの説明は省きます。
- 不正確な簡略化はしないでください。読者の行動を変える詳細は、1 行で記載します。
- コード抜粋と表を除き、文章は 600 語未満にしてください。
アンチパターン
- 番号付きの手順を、各段階の説明と「確認：」の段落で構成すること。
- WHERE 句、認証チェック、ステータス式を示さず、言葉で説明すること。
- 粗雑な部分を「意見が分かれるかもしれない決定事項」の箇条書きに隠すこと。コードに含まれているなら、そのコードを示してください。
- 「コードを見せましょうか？」と、コードを後回しにすること。読者が求めているのはレビュー用の要約です。コードそのものが要約です。
- PR の説明の草案を本文に含めること。ファイルに保存して、リンクしてください。