receiving-code-review

概要

receiving-code-review スキルでできること

receiving-code-review スキルは、特に GitHub の pull request に対するコードレビュー フィードバックをエージェントが受け取ったとき、どう応答すべきかの明確で再現性あるパターンを定義します。社交的なパフォーマンスではなく技術的な評価に主眼を置いています。

レビューアにただ盲目的に同意したり、即座に提案どおり実装したりするのではなく、このスキルはエージェントに以下のような振る舞いを求めます。

• 反応する前にすべてのフィードバックを読む
• 要求されている変更内容を言い換えたり、あいまいな点を確認したりする
• 実際のコードベースと照らしてフィードバックを検証する
• そのリポジトリにとって提案内容が技術的に妥当か評価する
• お世辞ではなく、根拠のある技術的な理由づけで応答する
• 理解と検証を済ませたうえで、変更を 1 件ずつ実装する

このスキルが向いている人

次のような場合は receiving-code-review の利用を検討してください。

• GitHub の PR やコードレビューで AI アシスタントを使っている
• アシスタントに「何でもイエスと言う存在」ではなく、思慮深いレビューア／レビュイーとして振る舞ってほしい
• レビューコメントの意図を解釈し、次に何をすべきか判断する際の助けがほしい
• 速くて表面的な合意よりも、変更の正しさや安全性を重視している

特に、次のような場面で有用です。

• 機能ブランチや pull request で共同開発している開発者
• レビュー フィードバックの扱い方を一貫させたいテックリード
• Claude やその他の LLM を PR レビューのパートナーとして試しているチーム

このスキルが向いていない場面

このスキルは次のような用途には向いていません。

• ゼロからの新機能の生成
• レビュー文脈のない大規模リファクタリング
• 社交辞令、賞賛、ステータス更新といったコミュニケーション

主にコード生成やドキュメントの下書き作成、上流の設計レビューが目的であれば、別のスキルと組み合わせて使ってください。receiving-code-review は、エージェントが コードレビューのフィードバックを受け取り、それに応答する局面に特化して利用するのが最適です。

主なメリット

receiving-code-review を導入すると、エージェントは次のように振る舞います。

• "You're absolutely right!" や "Great point!" のような、形だけの応答を避ける
• 仮定ではなく、実際のコードに基づいて応答する
• フィードバックが不明瞭なとき、推測ではなく明確な説明を求める
• 提案が技術的に誤っている場合は、敬意を保ちつつ反論する
• 誤解や有害な変更を実装してしまうリスクを減らす

これにより、code-review、git-workflows、pr-review といったプロセスで、エージェントをより信頼して使えるようになります。

使い方

1. インストール

obra/superpowers リポジトリから receiving-code-review スキルをインストールするには、次を実行します。

npx skills add https://github.com/obra/superpowers --skill receiving-code-review

このコマンドにより、SKILL.md を含むスキル定義がエージェントのスキル環境に取り込まれます。インストールには、事前に npx skills ツールが使える状態になっている必要があります。まだの場合は、利用しているプラットフォームやエージェントホストの手順に従って先にセットアップしてください。

2. インストール後に確認すべきファイル

インストール後、このスキルにとって中核となるファイルを確認します。

• skills/receiving-code-review/SKILL.md – コードレビュー フィードバックを受け取ったときの振る舞いパターンの正準的な定義

より広い obra/superpowers リポジトリ内には、共通パターンとして次のようなファイルがある場合があります。

• ルートの README.md、AGENTS.md、metadata.json など – スキルの構造と利用方法に関する全体的なコンテキスト

これらは receiving-code-review がより大きな Claude／エージェントのルールセットの中でどう位置付けられるかを理解するのに役立ちますが、このスキルの実務的な心臓部は SKILL.md にあります。

3. コアとなる応答ワークフロー

このスキルは、エージェントがコードレビュー フィードバック（例: GitHub の PR コメントスレッド）を受け取ったときの、具体的な応答パターンを定義しています。

1. READ:     反応する前にすべてのフィードバックを読む
2. UNDERSTAND: 要求を自分の言葉で言い換えるか、質問する
3. VERIFY:   実際のコードベースと照らしてフィードバックを検証する
4. EVALUATE: このリポジトリにとって技術的に妥当か判断する
5. RESPOND:  技術的な了承か、理由づけされた反論を行う
6. IMPLEMENT: 一つずつ変更し、それぞれテストする

実際には、次のような振る舞いになります。

• エージェントは、提案を即座に実装すると宣言してはいけません。
• まず、レビューアが何を求めているかを正確に理解します。
• 関連するファイル／行、あるいはリポジトリの状態を確認します。
• そのうえで、提案をそのまま採用するか、修正して採用するか、あるいは却下するかを判断します。

このパターンは、コンテキストと正確さがスピードより重要になる GitHub pull request review の場面で特に有用です。

4. 禁止される／望ましくない応答

このスキルは、LLM にありがちだが真剣なコードレビューでは有害となる応答を明示的に禁止しています。

禁止される例:

• "You're absolutely right!"（上位の CLAUDE ルールに対する違反として明示的に指定）
• "Great point!" や "Excellent feedback!" といった、賞賛だけの応答
• 提案をまだ検証していないのに "Let me implement that now" と言うこと

代わりに、receiving-code-review を有効にしているときは、エージェントは次のように振る舞うべきです。

• 技術的な要件を言い換える（例: "You are asking to extract this logic into a separate function to avoid duplication." のように意図を明確化する）
• 不明点がある場合は、的を絞った質問を行う
• 提案が誤っている、あるいは不十分だと判断した場合は、その理由を技術的に説明する
• 過度な説明や賞賛に走らず、実際の変更へと着実に進める

これにより、会話の焦点をお世辞ではなくコード品質に保つことができます。

5. あいまい／部分的なフィードバックへの対応

このスキルは、あいまいなフィードバックに関する厳格なルールを定めています。

IF any item in the feedback is unclear:
  STOP – do not implement anything yet
  ASK for clarification on the unclear items

理由は次のとおりです。個々のレビュー項目は互いに関連していることがあり、「理解したつもり」のものだけを実装し、あいまいなものを放置すると、

• 変更同士の矛盾
• ワークフローの破綻
• レビューアの意図とずれた挙動
  といった問題につながりかねません。

たとえば、レビューアが「Fix 1–6」と書き、エージェントが 1, 2, 3, 6 だけ理解できている状態だとします。このとき receiving-code-review は、次のような行動を促します。

• 実装を一時停止する
• 4 と 5 について、具体的な確認質問を行う
• 要件全体が理解できてから実装に進む

この振る舞いは、自動化／半自動化された git ワークフローにおいて特に重要です。部分的な理解のまま進めると、すぐに壊れたブランチを生み出してしまうからです。

6. GitHub／PR ワークフローとの統合

実プロジェクトで receiving-code-review を最大限に活用するには、次のように設定します。

1. このスキルを、次の用途で使うエージェントに付与する

   • pull request のレビュー
   • レビューコメントへの返信案の作成
   • レビュー フィードバックのトリアージや要約

2. エージェントがリポジトリにアクセスできる状態を確保する
   そうすることで、次の対象に対して提案内容を検証できます。

   • 現在のブランチのコード
   • 関連するファイルやモジュール

3. 他の補完的なスキルと組み合わせて使う

   • 合意済みの変更を実装するためのコーディング／リファクタリング スキル
   • 影響範囲のコードをすばやく見つけるためのリポジトリ ナビゲーションや検索スキル

4. チームに、このエージェントの振る舞いを共有する

   • 推測ではなく、必要に応じて明確化の質問をすること
   • 誤ったりリスクの高い提案には、時に反論すること
   • 一般的なお世辞ではなく、具体的な技術的応答を優先すること

このように統合すれば、receiving-code-review は、コードレビューの会話の中で AI コラボレーターを規律正しく信頼できる存在に保つ「ガードレール」として機能します。

7. このスキルを有効にすべきタイミング

次のようなプロンプトやワークフローになっているときは、receiving-code-review を有効にします。

• 人間やボットからの pull request のフィードバックを読んでいる
• GitHub の diff ビュー上のインラインコメントを確認している
• コードレビュー ツール内のレビュー ノートを処理している

一方、次のような場面では、このスキルは基本的に不要です。

• 初期のコードや機能の最初のドラフトを生成している
• 設計ドキュメントや ADR を執筆している
• 依存関係のアップグレードのような、レビューとは無関係な作業をしている

レビュー文脈に限定してスキルを有効化することで、エージェントの振る舞いを予測しやすく、レビューに集中させることができます。

FAQ

receiving-code-review はどんな問題を解決しますか？

receiving-code-review スキルは、コードレビュー フィードバックに対する AI の「浅く見せかけだけの応答」という問題を解決します。常に同意してすぐにコードを変えるのではなく、エージェントは次のように振る舞います。

• すべてのフィードバックを読む
• 既存のコードベースと照らして検証する
• あいまいな要望は明確にしてもらう
• 必要に応じて、技術的な根拠を示して反論する

これにより、GitHub の PR やその他のコードレビュー ツールにおける誤った実装やコミュニケーションミスを大幅に減らせます。

receiving-code-review はどうやってインストールしますか？

obra/superpowers リポジトリから次のコマンドでインストールします。

npx skills add https://github.com/obra/superpowers --skill receiving-code-review

インストール後は、receiving-code-review スキルディレクトリ内の SKILL.md を確認し、具体的な振る舞いルールを把握してください。

このスキルはコードの書き方に影響しますか？

間接的には影響します。receiving-code-review 自体はコードを生成しませんが、次のような方針を徹底することで、コード変更のタイミングとやり方に強く影響します。

• 実装前の検証
• 項目ごとに分けた変更とテスト
• 部分的で誤解に基づく修正の回避

レビュー フィードバックの妥当性を確認したうえで実装する部分は、コーディング系スキルと組み合わせて任せてください。

receiving-code-review は人間のレビューアに反論できますか？

できます。このスキルは、次のような場合に、理由づけされた技術的な反論を積極的に行うことを許容・推奨しています。

• 現在のコードベースと合致しないフィードバック
• 古い前提に基づいた指摘
• バグやリグレッションを招きそうな提案

ただし、その反論は意見ではなく、リポジトリ内の具体的な事実に根ざしたものでなければなりません。

このスキルは GitHub 専用ですか？

このスキルは GitHub 形式の PR review ワークフローを想定して書かれていますが、構造化されたコードレビュー フィードバックをエージェントが受け取るあらゆる環境に適用できます。たとえば次のようなケースです。

• Git ベースのコードレビュー ツール
• 社内のレビュー ダッシュボード
• 特定ファイルや行を参照するコメントがやりとりされるチャット形式のレビューセッション

ワークフローが「PR コメント + git リポジトリ」に近い形であれば、receiving-code-review は良い適合性を持ちます。

CLAUDE など他のエージェントルールとはどう連携しますか？

obra/superpowers エコシステムでは、スキルはより上位のルール（通常は CLAUDE.md のようなファイルに記載）とレイヤー構造で組み合わさります。receiving-code-review は、「You're absolutely right!」のような応答を禁じることで、そうした上位ルールの趣旨を具体化しています。

既存のエージェントルールと併用して、次のような効果を狙えます。

• レビュー時の振る舞いをより厳格にする
• 社交的な過剰最適化を避ける
• プロジェクトやリポジトリを跨いで一貫性を保つ

チームがもっと丁寧な応答を好む場合はどうすればよいですか？

このスキルは、丁寧さよりも明確で技術的なコミュニケーションを優先しますが、それでもプロフェッショナルなトーンは維持できます。もしよりソフトな言い回しが必要な場合は、

• トーンに関する別のガイドラインを他のスキルとして追加する
• 検証と厳密さの骨格としては receiving-code-review を維持する

といった形で役割を分けるとよいでしょう。スタイルを調整しても、レビューの規律そのものは弱めないようにできます。

このスキルが正しく機能しているかどうかは、どう確認できますか？

receiving-code-review が有効に機能しているサインとして、次のようなものが挙げられます。

• レビューコメントに対して、汎用的なお世辞だけで返すことがなくなる
• 行動に移る前に、要求を言い換えて確認する
• フィードバックが不完全またはあいまいなとき、質問して補完しようとする
• 提案を受け入れるときも異議を唱えるときも、特定のファイル、関数、行を参照する

もし検証なしに即座に "I’ll implement that" と答えるようであれば、スキル構成を見直し、レビュー文脈でこのスキルが有効になっているか確認してください。