requesting-code-review
レビューを別のエージェントに出させる。会話の履歴は渡さず、組み立てた文脈だけを渡す
npx skills add obra/superpowers/requesting-code-review入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 268,699
- 実用度
- 34
- GitHub star
- 313,505
- 最終更新
- 2026/11/4
頼み方の例
そのままコピーして使えますrequesting-code-reviewを使って、直前のコミットから現在までの変更をレビューに出してください。会話の履歴は渡さず、何を作ったかと要件だけを渡してください。指摘が返ったら重大なものから整理して見せてください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- シェルコマンドを実行する記述があります
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
コードブロックの言語: bash
いつ使うか
作業が一区切りついて、取り込む前に見てもらいたいときです。
誰に見せるかではなく、何を渡すか
このスキルの中心は誰に見せるかではなく、何を渡すかにあります。本文の 1 段落目が言い切っています。
レビュー役のサブエージェントを出して、問題が波及する前に捕まえる。レビュー役には精密に組み立てた文脈が渡される。あなたのセッションの履歴ではない。
中核の原則も 1 行で書かれています。「早く、何度も」。
会話の履歴を渡さない理由
本文は、よくある言い訳を表で潰しています。
| 言い訳 | 返し |
|---|---|
| 自分で差分を読めばいい | あなたは進行役。差分を読むと、作業を進めるための文脈を焼く |
| 履歴が無いと変更を理解できない | 履歴を渡すと、レビュー役が思考の過程を見てしまう |
2 つ目が本質です。会話の履歴には「最初こう考えたがやめた」が入っています。それを読ませると、成果物ではなく経緯を評価しはじめます。
渡すのは 4 つだけ
- 説明何を作ったかの短い要約
- 要件それが何をするべきか
- 開始の SHAどこから
- 終了の SHAどこまで
テンプレートが同梱されています（code-reviewer.md）。
テンプレートが見直し役に課すこと
テンプレートは、見直し役に読むだけを求めています。作業ツリー・index・HEAD・枝の状態を一切変えず、別の版が要るなら一時フォルダに worktree を作る、という指示です。
見直し役がさらにサブエージェントを出すことも禁じています。返ってくる形は「良い点・指摘（Critical／Important／Minor）・提案・判定」で、判定は取り込めるか（はい／いいえ／直せば可）を明言させます。
いつ出すかが決まっている
必須
サブエージェント駆動の各タスクのあと／大きな機能を作り終えたあと／主幹に取り込む前
任意だが有効
行き詰まったとき／大きく直す前の基準として／込み入った不具合を直したあと
「行き詰まったときに新しい視点」が任意に入っているのが実務的です。
指摘の扱い方が決まっている
- Criticalすぐ直す
- Important先へ進む前に直す
- Minorあとで、として記録する
そして「レビュー役が間違っていたら押し返せ」とも書かれています。技術的な理由を添えて、コードやテストで示す。無条件に従わせない作りです。
やってはいけないことが 4 つ
- 「簡単だから」でレビューを飛ばす
- Critical を無視する
- Important を未修正のまま進む
- 正しい技術的指摘に反論する
最後の 1 つと「間違っていたら押し返せ」は矛盾しません。正しいかどうかで分けるという指示です。
受け取る側は別スキル
返ってきた指摘をどう扱うかは receiving-code-review の担当です。出す側と受ける側が分かれています。
使わないほうがいいとき
サブエージェントを出せない環境では成立しない
別の文脈でレビューさせることが設計の中心です。同じセッションで差分を読ませるなら、このスキルを通す意味がありません。
git を使っていない対象には合わない
基準と終点を SHA で指定する作りです。
設計の相談には向かない
これは出来上がったものを見る工程です。作る前に詰めたいなら brainstorming の側です。
完了の宣言そのものを確かめたいなら別物
「終わった・直った・通った」を言う前の確認は verification-before-completion が担当しています。
注意点
解析では外部通信・書き換えの記述は見つかっていない
SKILL.md の解析では、外部通信・ファイル書き換えの記述は見つかっていません。同梱ファイルは 1 件です（2026-10-09 確認）。
開始の SHA は、直前のコミットか主幹との分岐点
開始の SHA の例は、直前のコミット（HEAD~1）か、主幹との分岐点（git merge-base origin/main HEAD）です。複数のコミットにまたがる変更なら、分岐点のほうが取りこぼしがありません。
ただし実際には git を操作する
ただし実際には git を操作します。 git rev-parse と
git log で SHA を取る手順が本文に入っています（スキルを入れる前に確認すること）。
レビュー役に渡す文脈は自分で決まる
レビュー役の指摘が正しいとは限らない
本文自身が押し返しを許しています。返ってきた指摘を無条件に反映させないでください。
サブエージェントぶんの実行が増える
タスクごとに出すと、その回数だけ別のエージェントが走ります。費用と時間の見積もりに入れてください。
ライセンスは MIT
ライセンス: MIT。再配布や商用利用の前に公開元の表記を確認してください。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
review-loop
作った成果物を別のサブエージェントに 1〜10 で採点させ、指摘を直しては採点し直す往復を回させる。既定は最低 2 回・最大 4 回で、8 以上になったら仕上げに進む。採点役は作り手と同等以上の能力にする
receiving-code-review
レビューの指摘に「おっしゃるとおりです」と返させない。検証してから直す
subagent-driven-development
計画をタスクごとに別のエージェントへ投げて、毎回レビューを通させる。途中で人に相談させない
verification-before-completion
「終わった」と言う前に証拠を要求する。主張ごとに何を走らせるかの表がある
よくある質問
なぜ会話の履歴を渡さないのですか
レビュー役が思考の過程を評価しはじめるからです。履歴には「最初こう考えたがやめた」が入っています。
渡すのは、何を作ったか・何をするべきか・開始の SHA・終了の SHA の 4 つだけです。
自分で差分を読んではいけませんか
本文は勧めていません。進行役が差分を読むと、作業を進めるために必要な文脈をそこで使ってしまいます。
差分と評価はレビュー役の文脈に置き、返ってくるのは指摘だけにする設計です。
指摘に反論してもいいですか
技術的な理由があるなら押し返せ、と書かれています。コードやテストで動くことを示すか、説明を求める。
一方で「正しい技術的指摘に反論するな」ともあります。正しいかどうかで分けてください。
いつ出せばいいですか
必須は 3 つ。サブエージェント駆動の各タスクのあと、大きな機能を作り終えたあと、主幹に取り込む前です。
行き詰まったときに出すのも有効だと書かれています。
対応しているエージェントはどれですか
Claude Code と Codex です。公開元は群の入口（using-superpowers）に実行環境ごとの補足ファイルを置き、writing-skills では Claude Code・Codex・Copilot CLI・Gemini CLI の置き場所まで書き分けています。
当サイトは公開元が明記しているものだけを表示しています（指標の意味と限界）。