requesting-code-review
作成者 obraタスク完了時や大きな機能の実装後、マージ前に、成果物が要件を満たしているか確認するために使います。
概要
スキルでできること
requesting-code-review スキルは、変更をマージする前に AI のコードレビュー用サブエージェントにチェックしてもらうための、明確で再現性のあるワークフローを定義します。Git ベースのプロジェクト向けに設計されており、次のようなことに役立ちます。
- レビューを依頼する タイミング を決める（タスク完了時、機能実装後、マージ前）
- Git SHA と要件を使って、レビュアーに渡す 的確なコンテキスト をまとめる
- レビュアーのフォーカスを、あなたのセッション履歴ではなく コードの差分 に絞る
- フィードバックを重要度別に分類し、今すぐ修正すべきものと後回しにできるものを切り分ける
本質的には、requesting-code-review は 早く・こまめにレビューする ことを促し、問題がコードベース全体に波及する前に発見するためのスキルです。
想定ユーザー
このスキルは次のような人に向いています。
- Git を使い、日常的に feature branch や PR を作成している
- AI によるコードレビューを 構造的かつ再現性のある形 で依頼したい
code-reviewerのようなサブエージェント駆動開発を行っている- 本番投入前の品質（正しさ、アーキテクチャ、テスト、仕様との整合性）を重視している
特に有用なのは次のようなケースです。
- しっかりしたセーフティネットが欲しい個人開発者
- 専任のコードレビュアーがいない小規模チーム
- コミット履歴と diff が主なソース・オブ・トゥルースになっているプロジェクト
不向きなケース
次のような場合、requesting-code-review は最適ではないかもしれません。
- Git を使っていない、または commit SHA にアクセスできない
- 特定の変更のレビュー ではなく、一般的なコード生成やリファクタリング支援を求めている
- レビュー対象の変更について、明確な計画・仕様・要件を提示できない
このような場合は、レビュー特化のワークフローではなく、より一般的なコーディングや計画用スキルを検討するとよいでしょう。
解決したい課題
一貫したレビュー手順がないと、開発者は次のような問題に陥りがちです。
- 重要なマイルストーンでレビュー依頼をし忘れる
- コンテキストをほとんど共有しない（またはセッション履歴を過剰に共有してしまう）
- フィードバックが構造化されておらず、具体的なアクションに落とし込みづらい
requesting-code-review スキルは、次のようにしてこれらの問題を解決します。
- 必須・任意のレビューのチェックポイント を定義する
- レビューの 入力形式（Git のレンジ、要件、サマリ）を標準化する
- 専用の
code-reviewerサブエージェントと組み合わせ、重要度順に整理されたフィードバック を返す
使い方
インストール
obra/superpowers リポジトリから requesting-code-review スキルをインストールするには、Skills CLI を使います。
npx skills add https://github.com/obra/superpowers --skill requesting-code-review
これにより、スキル定義と、code-reviewer サブエージェントのテンプレートを含む関連ファイルが取り込まれます。
インストール後、スキルのディレクトリを開き、まず次のファイルに目を通してください。
SKILL.md– コードレビュー依頼用の高レベルな説明とワークフローステップcode-reviewer.md– 実際にコードレビューを行うエージェントのプロンプト／テンプレート
コアワークフローの全体像
requesting-code-review のワークフローは、主に 3 フェーズで構成されます。
- レビューのタイミングを決める
- サブエージェント駆動ワークフローの各タスク完了後
- 大きな機能を作り終えたタイミング
- main ブランチにマージする前
- レビュー用のコンテキストを準備する
BASE_SHAとHEAD_SHAを使って Git のコミットレンジを取得する- 何を実装し、どう動くべきかを要約する
code-reviewer.mdに定義されているプレースホルダを埋める
- レビューを実行し、フィードバックへ対応する
superpowers:code-reviewerサブエージェントを実行する- Critical は即時対応、Important は先に片付け、Minor は記録のみにする
ステップ 1: 適切なレビュータイミングを見極める
SKILL.md によると、requesting-code-review は次のような場面で使います。
必須チェックポイント:
- サブエージェント駆動開発における 各タスク完了後
- 大きな機能を作り終えた後
- main ブランチ（例:
main,master）へ マージする前
任意だが有用なチェックポイント:
- 開発が 行き詰まった ときに、新しい視点が欲しい場合
- リファクタリング前 に、現状の動作をベースラインとして確認したい場合
- 複雑なバグ修正 の後に、リグレッションや新たな問題がないか確かめたい場合
これらのタイミングでこのスキルを起動する習慣をつけることで、レビューが「後回しの作業」ではなく、自動的なプロセスとして定着します。
ステップ 2: Git のコミットレンジを取得する
レビュアーには、ノイズの少ない明確な diff を渡す必要があります。Git SHA を使ってレンジを指定します。
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
BASE_SHAは、以前のコミットやorigin/mainの先頭など、あなたの 開始点 を示すコミットを指すようにします。HEAD_SHAは、あなたの 最新の変更 を含むコミットを指します。
ブランチ戦略に合わせて HEAD~1 を変えたり、別のベースを選んでも構いません。重要なのは、レビューしたい変更を正確にカバーするレンジを指定することです。
ステップ 3: レビューリクエストのテンプレートを準備する
code-reviewer.md は、Code Review Agent への指示方法を定義するファイルです。ここには、サブエージェントを実行する前に埋めるべきプレースホルダが用意されています。
主なプレースホルダ:
{WHAT_WAS_IMPLEMENTED}– 今回実装・変更した内容の簡潔な説明{PLAN_OR_REQUIREMENTS}– 実装が満たすべき仕様、チケット、ビジネス要件{BASE_SHA}– diff の開始点となるコミット SHA{HEAD_SHA}– diff の終点となるコミット SHA{DESCRIPTION}– 変更セットの短いサマリ（例: "Add verification function and tests for user signups"）{PLAN_REFERENCE}– 計画や要件ドキュメントへの参照
自分のツールチェーンの中で、これらのプレースホルダに値を埋めたうえで、Task tool を使って superpowers:code-reviewer サブエージェントを実行します。
ステップ 4: code-reviewer サブエージェントを実行する
Git SHA とテンプレートの準備ができたら、以下の手順で進めます。
-
superpowers framework で説明されているように、オーケストレーション環境の Task tool を使い、type に
superpowers:code-reviewerを指定します。 -
プレースホルダを実際の値に置き換えた
code-reviewer.mdの内容を渡します。 -
エージェントが指定レンジの Git diff にアクセスできるようにします。
git diff --stat {BASE_SHA}..{HEAD_SHA} git diff {BASE_SHA}..{HEAD_SHA}テンプレートにはこれらのコマンドが示されており、レビュアーが
BASE_SHAとHEAD_SHA間の変更だけに集中できるようになっています。
このスキルの設計により、レビューエージェントに見せるのは コミットと diff といった成果物のみ であり、広範なセッション履歴や無関係なコンテキストは共有されません。
ステップ 5: フィードバックを解釈し、対応する
code-reviewer.md テンプレートは、エージェントに次の観点でレビューするよう指示します。
- コード品質（関心の分離、エラーハンドリング、DRY、エッジケース）
- アーキテクチャ（設計、スケーラビリティ、パフォーマンス、セキュリティ）
- テスト（カバレッジ、統合ポイント、テストケースの質）
- 要件の確認（仕様との整合性、スコープ逸脱の有無、破壊的変更の明示）
- 本番準備性（マイグレーション、後方互換性、ドキュメント）
フィードバックは次のカテゴリに分類されます。
- Critical (Must Fix) – バグ、セキュリティ問題、データ損失リスク、機能の破壊
- Important (Should Fix) – アーキテクチャ上の問題、欠けている機能、不十分なエラーハンドリング、テスト不足
- Minor (Nice to Have) – スタイル、最適化、ドキュメント改善
SKILL.md で示される対応フローは次のとおりです。
- Critical な問題は作業を進める前に必ず修正する
- Important な問題も、さらなる開発やマージの前に解消しておく
- Minor な事項は、後でのクリーンアップやフォローアップタスクとして記録しておく
- レビュアーが誤っている・コンテキストを理解していないと判断した場合は、根拠を示してきちんと反論する
この重要度別トリアージに従うことで、AI のフィードバックを漠然とした提案ではなく、具体的なアクションリストに変換できます。
利用パターン例
典型的な requesting-code-review の利用例は次のような流れです。
-
feature branch で「Task 2: Add verification function」を完了する。
-
次のように SHA を取得する。
BASE_SHA=$(git rev-parse origin/main) HEAD_SHA=$(git rev-parse HEAD) -
code-reviewer.mdのプレースホルダを次のように埋める。{WHAT_WAS_IMPLEMENTED}= "Verification function for user email flow"{PLAN_OR_REQUIREMENTS}= チケットや要件のリンク／要約{BASE_SHA}と{HEAD_SHA}= Git から取得した値{DESCRIPTION}= "Implement email verification and add tests for edge cases"
-
Task tool を使って
superpowers:code-reviewerサブエージェントを実行する。 -
Critical / Important / Minor に分類された構造化フィードバックを受け取る。
-
Critical と Important を解消し、必要に応じてマージ前に再度同じプロセスを回す。
FAQ
requesting-code-review は GitHub リポジトリ専用ですか？
いいえ。requesting-code-review は Git ベース であり、GitHub 専用ではありません。commit SHA と git diff コマンドに依存しているため、BASE_SHA と HEAD_SHA を指定できる Git のリモート（GitHub, GitLab, Bitbucket, 自前ホスティングなど）であればどこでも使えます。
開発セッションの全履歴を共有する必要はありますか？
いいえ。requesting-code-review の重要な設計思想のひとつは、レビュアーに渡すコンテキストを 狭く適切な範囲に絞る ことです。共有するのは「何を実装したか」「要件は何か」「Git diff」のみであり、一般的なセッション履歴や思考プロセスは非公開のまま、レビュアーは実際のコード変更に集中できます。
ワークフローのどのタイミングで requesting-code-review を実行すべきですか？
requesting-code-review の利用タイミングは次のとおりです。
- サブエージェント駆動開発の各タスク完了後
- 大きな機能を作り終えた後
- main ブランチへのマージ前
さらに、詰まったとき、大規模なリファクタリングの前、複雑なバグ修正の後などに実行しておくと、潜在的なリスクの早期検知に役立ちます。
既存の Pull Request レビューとはどう統合できますか？
requesting-code-review は、人間による PR レビューの 代替ではなく補完 として機能します。例えば次のような使い方ができます。
- PR を作成する 前に このスキルを実行し、明らかな問題を事前に潰す
- 人間のレビュアーと 並行して 実行し、レビュー範囲と一貫性を高める
- ここで使われる Critical / Important / Minor の分類を、PR コメントの整理にも活用する
このスキルは Git のレンジを前提にしているため、PR ベースの開発フローにも自然に組み込めます。
code-reviewer エージェントの挙動はカスタマイズできますか？
はい。code-reviewer.md はカスタマイズ可能なテンプレートです。
- コード品質、アーキテクチャ、テスト、セキュリティに関するチェック項目を調整する
- ドメイン固有のルールやパフォーマンス予算など、プロジェクト特有の観点を追加する
- 重要度のレベルや出力セクションを変更したい場合、出力フォーマットを調整する
ただし、レビューをフォーカスされ実行可能なものに保つため、タスクの明確化・Git レンジ・重要度カテゴリというコア構造は維持することをおすすめします。
レビュアーの指摘が間違っていた場合はどうすればよいですか？
このスキルでは、レビュアーが誤っている・コンテキストが不足していると感じたときに、理由を示してきちんと反論する ことを明示的に推奨しています。レビュー結果を絶対的な判定ではなく、強い提案として扱ってください。制約条件やトレードオフを説明したり、必要に応じて計画を更新したりすることで、次回以降のレビュー精度も高められます。
requesting-code-review はテストやコードを自動生成してくれますか？
いいえ。このスキルは 生成ではなくレビュー専用 です。できるのは次のようなことです。
- 特定の変更にフォーカスしたレビューを依頼する
- 品質・アーキテクチャ・テストに関する構造化されたフィードバックを受け取る
実際の修正やテスト作成は、あくまであなたの責任です。ただし、他のコーディングスキルやテスト生成スキルと組み合わせてツールチェーンを構成することは可能です。
すぐに試すにはどうすればよいですか？
-
スキルをインストールします。
npx skills add https://github.com/obra/superpowers --skill requesting-code-review -
SKILL.mdを読み、レビューのチェックポイントを理解します。 -
code-reviewer.mdに目を通し、エージェントのチェックリストと出力フォーマットを確認します。 -
次のタスクや機能を実装し、
BASE_SHAとHEAD_SHAを取得してから、superpowers:code-reviewerサブエージェントを実行します。
あとは、テンプレートやワークフローをチームの開発習慣や品質基準に合わせて調整し、自分たちにフィットした requesting-code-review の運用方法に仕上げていきましょう。