code-review

code-review スキルの概要

code-review スキルは、コミットやデプロイの前にコード変更をレビューするための必須ワークフローです。特に、曖昧な「問題なさそう？」というプロンプトに頼るのではなく、/code-review という再現性のある手順で、ざっくりした変更セットを構造化されたレビューに落とし込みたい開発者やチームに向いています。

code-review スキルの強みは、エンジン選択にあります。変更の規模、リスク、複雑さに応じて、Claude、OpenAI Codex、Google Gemini、または複数エンジンのワークフローに振り分けられます。そのため、速度よりもレビュー品質を重視したい場面、とくにマージ前チェック、リリース候補、高リスクなリファクタリングに適しています。

これは単なるチェックリストではありません。code-review スキルは、すでに変更済みファイルや diff、明確なレビュー対象がある段階で呼び出すことを前提に設計されており、変更を差し止めるにも承認するにも十分実用的なフィードバックを返せます。

code-review を導入すべき人

AI支援またはツール支援の開発ワークフローに、一貫したレビューゲートを入れたいなら code-review スキルを導入する価値があります。特に、個人開発者、小規模チーム、そしてコードを出す前に予測可能なレビュー手順が必要なエージェントに向いています。

すでにコードレビューは必須なのに、運用が毎回バラバラという場合、このスキルはより明確な実行パターンを与えてくれます。逆に、断片的なコードに対してたまにスタイル指摘をもらえれば十分なら、通常のプロンプトで足ります。

何の問題を解決するのか

主な役割は、レビューの曖昧さを減らすことです。「このコードをレビューして」とだけ頼んで曖昧な合格判定が返ってくるのではなく、code-review スキルならエンジン選択、範囲、求める厳密さを明確にできるため、実際の問題を拾いやすくなります。

これは、次のような場面で特に重要です。

• コミット前のレビューゲート
• デプロイ前の安全性チェック
• 大きな変更の後の二重チェック
• 正しさ、保守性、リスクをまたいだ広いレビュー

何が特長なのか

code-review スキルは、判断を前提にした設計です。最も実用的な差別化ポイントは、単一のモデルや単一の分析スタイルに縛られず、レビューエンジンを選べることです。

その結果、次のような使い分けができます。

• ローカル文脈や手軽さを重視するなら Claude
• コード中心のレビューなら Codex
• より長いコンテキストが必要なら Gemini
• 相互確認で精度を上げたいなら複数エンジン

code-review スキルの使い方

インストールして起動する

まずは自分の環境に合わせて、リポジトリのスキル導入フローに従ってインストールします。そのうえで、確認したいコードがあるタイミングで /code-review を実行します。このスキルはユーザーが直接呼び出す前提なので、広いアシスタント用プロンプトの中に埋め込むのではなく、ワークフローの一部として明示的に呼ぶ設計です。

リポジトリの抜粋では allowed-tools: [Read, Glob, Grep, Bash] が示されており、これは貼り付けられた断片だけを見るのではなく、ファイル本体と周辺コンテキストを確認する用途を想定していることを意味します。

レビューしやすい入力を渡す

code-review スキルは、レビュー対象とレビュー理由がはっきりしているほど効果を発揮します。良い入力には、たとえば次の情報が含まれます。

• ブランチ、PR、またはコミット範囲
• 変更されたファイル
• 変更の種類: bug fix、refactor、feature、dependency update
• リスクレベル: low、medium、high
• レビュー観点: correctness、security、tests、API behavior、performance

弱いプロンプトは「コードをレビューして」です。
強いプロンプトは、「src/login.ts と src/session.ts の auth リファクタに対して /code-review を実行して。main にマージする前に、回帰、エッジケース、テスト不足を重点的に見てほしい」です。

先に確認すべきファイルを読む

最初に SKILL.md を読みます。ここにワークフローとエンジン選択の定義があるからです。次に、環境内でこのスキルの振る舞いを左右するリポジトリ指示を確認します。README.md、AGENTS.md、metadata.json、および存在する場合は関連フォルダも見てください。

このリポジトリでは中核のガイダンスが SKILL.md にまとまっているため、実際の導入判断はかなりシンプルです。レビューのワークフローが欲しいなら、そのファイルが主たる正本になります。

エンジン選択は意図して行う

code-review スキルの真価は、習慣ではなく変更内容に応じてレビューエンジンを選ぶところにあります。たとえば、次のように使い分けます。

• すばやく統合されたレビューが欲しいなら既定エンジン
• コード特化の分析が欲しいなら Codex
• 長文コンテキストがボトルネックなら Gemini
• リスクの高い変更で確信度を上げたいなら複数エンジン

どのエンジンを使うのか、その理由を指定しないと、レビューが一般論に寄りがちです。深さ、広さ、コンテキスト容量のどれを重視するのかを伝えてください。

code-review スキルの FAQ

code-review は通常のプロンプトより優れているのか？

はい、再現性のあるレビュー手順が必要なときは優れています。通常のプロンプトでもコードレビューはできますが、code-review スキルには構造化された入口、エンジン選択、そしてコミット前・デプロイ前というより明確な用途があります。

code-review スキルは初心者向けか？

レビュー対象のファイルや変更セットを特定できるなら、基本的には使いやすいです。何が変わったのか、何を確認したいのかが分かっているほど扱いやすくなります。差分も文脈もなく、具体的な質問もない場合は、あまり役に立ちません。

いつ code-review を使うべきではないか？

小さな断片の簡単な説明だけ欲しい場合や、まだアイデアを試している段階で正式なレビューをしたくない場合は使わないほうがよいです。また、実際のコード変更を検査することに価値があるスキルなので、コード以外の内容には最適ではありません。

code-review はエージェント型ワークフローに向いているか？

はい。code-review スキルは、コミットやデプロイ前のガードレールとして呼び出せるため、エージェントワークフローと相性が良いです。アシスタントが同じセッション内でコードを生成し、その後に検証することを求められる場面で特に有用です。

code-review スキルを改善する方法

レビュー対象をもっと狭くする

品質が最も上がるのは、曖昧さを減らしたときです。リポジトリ全体のレビューを求めるのではなく、コミット、diff、フォルダ、機能境界まで範囲を絞ってください。code-review スキルは、何が変わったのか、そしてその変更にとっての「良い状態」が何かを理解できるほど強くなります。

重視したいリスクを明示する

最良の code-review 出力は、優先順位がはっきりしているときに得られます。ロジックバグ、回帰、セキュリティ問題、テストカバレッジの不足、API の破壊、保守性の問題のどれを見てほしいのかを伝えてください。言わないままだと、レビューの注意が分散しやすくなります。

コメントだけでなく、判断を求める

目的がデプロイゲートなら、code-review スキルに findings の重大度を分類させ、マージして安全かどうかまで言わせてください。そうすると、曖昧な所見の羅列よりもずっと実用的な出力になります。

最初のレビューのあとに繰り返す

最初のレビューで問題が見つかったら、修正内容を渡して、更新後の diff に対してもう一度 /code-review を実行してください。このスキルは、レビュー、修正、再レビューというループで使うと最も価値があります。code-review を一度きりのプロンプトではなく、信頼できるリリース習慣に変えるには、この運用が重要です。