receiving-code-review

receiving-code-reviewスキルの概要

receiving-code-reviewスキルは何のためのものか

receiving-code-review スキルは、AIがコードレビューのフィードバックに対して、反射的に同意するのではなく、技術的に筋の通った対応を取れるようにするためのスキルです。役割はシンプルですが実用的です。レビュアーから変更提案を受けたら、エージェントはまずその意図を正しく理解し、実際のコードベースと照らし合わせて妥当性を確認し、そのうえで実装するか、異議を返すかを判断します。

特に効果を発揮するのは、レビューコメントが曖昧だったり、一部が誤っていたり、互いに矛盾していたり、そのまま適用すると危険だったりする場面です。receiving-code-review スキルは、PRスレッドで丁寧に見せるためのものではありません。問題が妥当かどうかを確かめる前に、「その通りです、直します」と反射的に返してしまい、結果として悪い変更を入れてしまう――そうした“社会的反射”を防ぐためのスキルです。

どんなユーザーに向いているか

このスキルが特に合うのは、次のようなケースです。

• PRコメントの処理をAIに手伝わせている開発者
• 表面的な同意より、技術的な正確さを重視したいチーム
• レビュアーの提案がローカルな制約に合わない可能性がある、成熟したコードベースで動くエージェント
• その場しのぎのプロンプトではなく、再現可能なレビュー対応フローを求めるユーザー

「モデルがレビュー指摘をすぐ実装してしまい、かえって壊す」というのが主な悩みなら、このスキルはまさにその失敗パターンを狙って対処します。

本当に片づけたい仕事

多くのユーザーは、コメントそのものを読む手助けを必要としているわけではありません。必要なのは、次の判断です。

• レビュアーが実際には何を求めているのか
• その提案がこのリポジトリにとって正しいのか
• 何かを変える前に確認質問が必要かどうか
• レビュアーの理解が不十分、または誤っている場合にどう返すべきか
• フィードバックが妥当なら、どう安全に実装するか

receiving-code-review スキルの実用価値はここにあります。レビューを「受け取る作業」から、「検証するワークフロー」へ変えてくれます。

一般的なレビュー用プロンプトとの違い

普通のプロンプトだと、モデルは従順な方向に寄りがちです。フィードバックを要約し、レビュアーに感謝し、そのまま編集に入ってしまいます。対してこのスキルは、次の応答パターンを明確に求めます。

1. フィードバック全体を読む
2. 要求内容を言い換える
3. コードベースの実態と照合する
4. 技術的に適合するか評価する
5. 受領、確認質問、または理由ある異議のいずれかで返す
6. 実装は一度に1項目ずつ進める

さらに、過剰なお礼や、妥当性確認前の即時コミットといった、価値の低い典型的な応答も明示的に禁止しています。

インストール前に知っておくべきこと

これは目的を絞った軽量スキルです。ヘルパースクリプト、参照資料、リポジトリ固有ルールなどは付属していません。導入しやすいという意味では利点ですが、その一方で、出力品質は入力するレビューコメントとコード文脈に大きく左右されます。

このスキルは、Code Reviewワークフロー向けの行動ガードレールとして捉えるのが適切です。フル機能のコードレビュー自動化フレームワークではありません。

receiving-code-reviewスキルの使い方

receiving-code-reviewスキルのインストール方法

obra/superpowers リポジトリからインストールします。

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

環境によって別の skill loader を使っている場合は、次の場所から追加してください。

https://github.com/obra/superpowers/tree/main/skills/receiving-code-review

このスキルについてリポジトリ側で公開されているのは SKILL.md のみなので、インストール後の確認や中身の把握はシンプルです。

リポジトリで最初に読むべきファイル

この receiving-code-review install を判断するなら、まず次を確認してください。

• skills/receiving-code-review/SKILL.md

このファイルに、実質的に必要な挙動がほぼすべて入っています。

• 中核となる原則
• 応答パターン
• 禁止される応答
• 不明確なフィードバックの扱い方

先に読むべき追加の rules/、resources/、補助スクリプトはありません。理解にかかる時間は短めです。

実運用で receiving-code-review を呼び出すタイミング

receiving-code-review skill は、フィードバックが届いた時点、つまりコード変更を始める前に使うのが基本です。

トリガーとして相性がいいのは、たとえば次のようなケースです。

• 「Please simplify this logic.」
• 「This should use a transaction.」
• 「Fix comments 1–6.」
• 「Why not just cache this?」
• 「Use pattern X instead.」

特に使うべきなのは、次のような場面です。

• コメントがまとめて投げられている
• 一部の項目が曖昧
• レビュアーがローカルなアーキテクチャ制約を把握していない可能性がある
• AIがすぐパッチを書き始めそうになっている

このスキルに必要な入力

このスキルが最も機能しやすいのは、次の4点がそろっているときです。

1. レビューコメントの原文
2. 影響を受ける file path または diff
3. コードベース上の関連制約
4. 次に何をしてほしいか

有用な入力の例は次のとおりです。

• PRコメントのコピペ原文
• 現在の実装
• テスト失敗やパフォーマンス上の制約
• 提案と衝突しうるアーキテクチャルール
• 返答文の下書きがほしいのか、評価がほしいのか、実装支援がほしいのか

コードベースの文脈がなくても、コメントの解釈までは手伝えます。ただし、技術的に適合するかの検証精度は大きく落ちます。

曖昧な依頼を強いプロンプトに変える

弱いプロンプト:

Handle this review feedback.

より強いプロンプト:

Use the receiving-code-review skill.

Review feedback:
"Please combine these queries and move validation into the controller."

Context:
- Files: app/services/order_sync.rb, app/controllers/orders_controller.rb
- Current pattern: validation is intentionally kept out of controllers
- This code handles retry behavior and partial failures
- I want to know whether the suggestion is correct for this codebase

Please:
1. Restate what the reviewer is asking
2. Identify any ambiguity
3. Verify the suggestion against the current design
4. Recommend whether to implement, ask a question, or push back
5. If valid, propose the smallest safe change

この形が優れているのは、スキルにとって重要な処理、つまり単なる言い換えではなく「検証」を行うための材料が揃っているからです。

receiving-code-review の実践ワークフロー

信頼できる receiving-code-review usage の流れは、次のようになります。

1. レビュースレッド全体、またはコメントのまとまりを貼る
2. 明確な項目と不明確な項目を分けるようエージェントに依頼する
3. 各変更要求を必ず言い換えさせる
4. 各項目をコードベースと照合させる
5. 実装・確認・不同意のどれを推奨するか判断させる
6. そこではじめて、1件ずつ編集に進む

こうすることで、コメントの束の一部だけを実装し、残りを誤解したまま進めてしまう典型的なミスを防げます。

曖昧なコメントや束ねられたコメントの扱い方

このスキルで特に強い考え方の一つが、「どれか1項目でも不明確なら、実装前に止まる」という点です。

実際のPRでは、コメント同士が依存していることがよくあります。たとえばレビュアーが「Fix points 1–6」と言っていて、4と5が曖昧な場合、1〜3と6だけ先に実装すると、全体として間違った方向に固定されてしまうことがあります。

この場面では、たとえば次のようなプロンプトが有効です。

Use receiving-code-review. Group this feedback into:
- clear and ready to verify
- unclear and needs clarification
Do not recommend implementation until all linked items are understood.

このスキルの良い出力はどんなものか

良い結果は、「Thanks, great catch.」のような返答ではありません。含まれているべきなのは、次の要素です。

• レビュアーの技術的要求を整理した明確な言い換え
• 前提や曖昧さの指摘
• 実際のコードに照らした検証
• 理由付きの判断
• 確認質問、丁寧な異議、または安全な実装計画のいずれか

コメントからそのままコード変更に飛んでいるなら、その receiving-code-review は正しく使えていません。

Code Review作業で使いやすいプロンプトパターン

目的に応じて、次のパターンを使い分けると効果的です。

評価だけしたい場合:

Use the receiving-code-review skill to evaluate whether this review comment is technically correct for this repository. Do not implement yet.

返答文を下書きしたい場合:

Use the receiving-code-review skill to write a concise technical reply to this PR comment. Avoid praise language. Ask for clarification if needed.

検証後に実装へ進みたい場合:

Use the receiving-code-review skill. First verify the reviewer's request against the codebase. If valid, propose the smallest testable change and list risks before editing.

出力品質を上げる実践的なコツ

入力を少し改善するだけで、結果は大きく変わります。

• あなたの要約ではなく、レビュアーの原文を入れる
• 対象関数だけでなく、その周辺コードも含める
• 指摘が style、correctness、performance、architecture のどれに関するものか明示する
• コードベース内で絶対に崩せない条件を伝える
• レビュアーが、根拠のない前提を置いている可能性がある箇所を特定させる

このスキルは、要求された変更とリポジトリの実態を比較できるほど、精度が上がります。

receiving-code-reviewスキル FAQ

receiving-code-review は PRコメントで人間に返信するときだけのものですか？

いいえ。実際に返信する前の内部評価にも同じくらい有効です。多くの場合、receiving-code-review の最初の使い方として最善なのは非公開の場です。公開の返答文を作る前に、そのコメントが正しいのか、不完全なのか、危険なのかを先に見極められます。

このスキルは初心者にも使いやすいですか？

はい。ただし注意点が1つあります。ワークフロー自体は理解しやすいものの、初心者はそのフィードバックがコードベースに合っているかを判断するための技術的文脈を、まだ十分に持っていないことがあります。このスキルは対応の規律を強化しますが、エンジニアリング上の判断そのものを代替するわけではありません。

普通の「このPRフィードバックを分析して」と何が違うのですか？

最大の違いは、即座に同意する挙動を内蔵で抑えていることです。SKILL.md にある receiving-code-review guide は、検証、確認、そして根拠のある異議申し立てを中心に据えています。一般的なプロンプトは、正しさよりも、角の立たないコミュニケーションを優先しがちです。

receiving-code-review を使わない方がいいのはどんなときですか？

タスクがすでに完全に定義されていて、機械的に安全に処理できる場合は、使わなくても構いません。たとえば次のようなケースです。

• 明らかな typo の修正
• 振る舞いに影響しない symbol の rename
• すでに文書化された、確認済みのチーム規約に従うだけの場合

また、他人のコードに対して包括的な outbound code review を行う用途にも向きません。このスキルはあくまで、「フィードバックを受ける側」として適切に対応するためのものです。

レビュアーが間違っているときにも receiving-code-review は役立ちますか？

はい。むしろそれが最も強い用途の一つです。このスキルは、防御的な態度や自動的な追従ではなく、理由を伴った技術的な返答を促します。レビュアーの提案がコードベースと食い違っているなら、その理由を説明し、より明確な返答案を出してくれるはずです。

まとめて来るレビューコメントにも対応できますか？

はい。ただし、コメントの束を丸ごと渡し、スキルに明確な項目と不明確な項目を切り分けさせることが前提です。このスキルは、「部分的にしか理解できていないなら実装を止めるべき」という立場を強く取ります。特に「これ全部直して」のような状況で役立ちます。

receiving-code-reviewスキルを改善するには

レビュアーの文面だけでなく、リポジトリの実態も渡す

receiving-code-review の出力を最も速く改善する方法は、コメントに加えて次をセットで渡すことです。

• file path
• 現在の実装断片
• 制約条件
• テスト
• 関連するアーキテクチャパターン

レビュー提案がローカルな設計判断に依存しているなら、抽象的なままでは正しく評価できません。

要約ではなく、判断を求める

弱い実行結果の多くは、プロンプトが単にフィードバックを「処理して」としか求めていないことが原因です。より良いプロンプトは、エージェントに明確な選択を迫ります。

• 実装する
• 確認質問をする
• 理由付きで異議を返す
• 文脈不足のため保留する

こうすることで、スキルは説明的なものではなく、実務で動くものになります。

最もよくある失敗パターンを防ぐ

最大の失敗パターンは、早すぎる実装です。モデルはレビュアーの提案を見ると、次を確認する前に編集へ進みがちです。

• レビュアーが現在のコードを正しく理解しているか
• 制約により提案が不適切になっていないか
• 他のコメントによって意味が変わっていないか
• 要求された変更に見えない副作用がないか

エージェントには明示的にこう伝えてください。Do not implement until verification is complete.

曖昧なレビュースレッドには、入力の枠組みを補う

フィードバックが曖昧なら、不足している枠組みをこちらで補うと効果的です。

Use receiving-code-review.

The reviewer says: "This flow should be simplified."
Please identify at least 3 plausible interpretations, map each to the current code, and tell me what clarification question would unblock implementation safely.

モデルに1つの意味を勝手に決めさせて、そのまま進ませるより、はるかに安全です。

異議は技術的に、簡潔に返す

レビュアーが誤っている場合、最良の出力は短く、具体的で、根拠に基づいています。次の観点を出力させるとよいでしょう。

• レビュアーが置いていそうな前提
• その前提と衝突するコードベース上の事実
• その不一致を説明するための、最小限で丁寧な返答

こうすることで、receiving-code-review for Code Review のワークフローは対立的にならず、実用性を保てます。

最初の回答のあとに再実行する

1回目の結果が出たら、まだ足りない情報を足して改善してください。

• レビュアーの意図の不明点
• 欠けているコード断片
• アーキテクチャ上の制約
• テスト上の証拠
• diff の文脈

2回目に使いやすいプロンプトは、たとえば次のとおりです。

Re-run receiving-code-review with this added context. Update your recommendation and tell me whether the original review comment is now clear enough to implement.

実装系のスキルと組み合わせるのは、検証後にする

導入パターンとして最も安定するのは、次の二段階です。

1. receiving-code-review でコメントを評価する
2. そのあとでコード編集を依頼する

この分離が有効なのは、モデルがファイルを変更し始める前に、判断の根拠を確認できるからです。

チームの標準運用として使う

チームとしてPRワークフローでのAI挙動をそろえたいなら、受け取ったレビュー対応のデフォルト指示としてこのスキルを組み込むのが有効です。

• まず褒めるだけの返答をしない
• 盲目的に実装しない
• 不明なら確認する
• ローカルコードと照合する
• 技術的に妥当なら異議を返す

receiving-code-review skill が最も長く価値を発揮するのは、一度きりのプロンプトとしてではなく、繰り返し使える運用習慣として定着したときです。