code-reviewer

code-reviewer skill の概要

code-reviewer は、AI を使った Code Review のための、焦点の絞られたレビュー用フレームワークです。大まかな 1 本のプロンプトに頼るのではなく、security → performance → correctness → maintainability という明確なレビュー順序と、重要度の高い問題を先に見つけるための具体的なルールをエージェントに与えます。多くのチームにとって本当に必要なのは、曖昧なスタイル指摘を量産することではなく、リスクの高い欠陥を早い段階で拾うことです。そういう意味で、code-reviewer skill は導入判断のしやすい、実務寄りのレビュー支援です。

code-reviewer を導入すべき人

code-reviewer は、PR レビューのばらつきを減らしたい開発者、レビュアー、AI エージェント利用者に向いています。とくに、レビュー観点をゼロから自作するのは避けたいが、毎回のレビュー品質は揃えたい、というケースに合います。Web アプリ、バックエンド、データベースアクセス層、あるいは Python / JavaScript のコードを扱い、security やデータアクセスのミスが高コストになりやすい環境では特に相性がいいです。

汎用的なレビュー用プロンプトと code-reviewer の違い

最大の違いは、code-reviewer skill が短い指示文だけで動くのではなく、明示的なルールファイルに支えられている点です。リポジトリには、次のような観点に対する個別ガイドが含まれています。

• SQL injection prevention
• XSS prevention
• N+1 query detection
• error handling
• naming clarity
• type hints

そのため、単に「このコードをレビューして」と投げるよりも、よくある高インパクトなレビュー観点に対して、再現性のある判断をしやすくなっています。

導入前に多くの人が最初に気にすること

インストール前に、多くのユーザーが知りたいのは次の点です。

1. 重要な問題を見つけてくれるのか、それとも細かい指摘ばかりになるのか？
2. フルリポジトリがなくても、差分だけで使えるのか？
3. スタイルだけでなく、security や performance も見てくれるのか？
4. セットアップはどの程度必要か？

この観点で見ると、code-reviewer は「問題の優先順位付け」と「導入の軽さ」は強みです。一方で、カバー範囲は意図的に狭く設計されています。含まれているルールに沿って、構造化されたレビューをしたい場合に最も力を発揮します。

向いているケース / 向いていないケース

向いているケース:

• merge 前の PR review
• 手早い security の健全性チェック
• DB アクセスコードのレビュー
• frontend の rendering / output 安全性チェック
• Python または JavaScript のコード品質レビュー

向いていないケース:

• 多数のサービスをまたぐ深い architecture review
• framework 固有 lint の代替
• compiler レベルの言語別 static analysis
• 正式な標準へのマッピングが必要な compliance 重視監査

code-reviewer skill の使い方

code-reviewer のインストール方法

エージェント環境が skills CLI をサポートしている場合は、upstream repository から次のコマンドで code-reviewer を追加できます。

npx skills add Shubhamsaboo/awesome-llm-apps --skill code-reviewer

その CLI を使わない構成であれば、awesome_agent_skills/code-reviewer/ を開き、skill のファイルを手動でエージェントのワークフローに読み込んでください。

最初に読むべきファイル

code-reviewer をうまく使うなら、まず次の順で読むのがおすすめです。

1. SKILL.md — この skill の目的とレビュー優先順
2. AGENTS.md — 例付きでまとめられたレビュー指針
3. rules/security-sql-injection.md
4. rules/security-xss-prevention.md
5. rules/performance-n-plus-one.md
6. rules/correctness-error-handling.md
7. rules/maintainability-naming.md
8. rules/maintainability-type-hints.md

この順で追うと、判断の軸から具体例までを短時間で把握できます。

実運用で効くレビュー優先順位

code-reviewer usage の実務上の強みは、レビュー順序が最初から組み込まれていることです。

1. Security
2. Performance
3. Correctness
4. Maintainability

プロンプトでもこの順序をそのまま指定すると効果的です。命名や整形にレビュー時間の半分を使ってしまい、injection リスクやデータベースの非効率を見逃す、というありがちな失敗を防ぎやすくなります。

code-reviewer に渡すべき入力

この skill は、次の情報を与えると精度が上がります。

• diff または変更ファイル
• language / framework
• user-controlled inputs
• database / query layer の詳細
• rendering / output context
• どの種類のレビューをしたいか: PR gate、security pass、または広めの品質レビュー

最小限の情報でも動きますが、データがどこから入り、どこに出ていくかが見えるほど、レビュー品質は大きく上がります。

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

弱いプロンプト:

Review this code.

より強いプロンプト:

Use the code-reviewer skill on this PR diff.
Prioritize findings in this order: security, performance, correctness, maintainability.
Focus especially on:
- SQL injection risk in database access
- XSS risk in rendered user content
- N+1 query patterns
- missing or weak error handling

For each finding, give:
1. severity
2. exact location
3. why it matters
4. a safer or faster alternative
5. whether it blocks merge

この形なら、リポジトリ内のルール設計と直接噛み合うため、エージェント側の推測に頼る部分が減ります。

pull request review でのおすすめ運用フロー

実用的な code-reviewer guide の流れは次のとおりです。

1. まず PR diff を渡す
2. blocking issue と high-severity issue のみに絞って出させる
3. それらを修正する
4. 2 回目のパスで correctness と maintainability を見る
5. patch suggestion は、指摘内容が固まってから求める

この 2 段階運用にすると、最初のレビューのシグナルが濃くなり、優先度の高い問題が中程度の改善提案に埋もれにくくなります。

ルールが実際に見つけやすい問題

同梱されているファイルから見る限り、code-reviewer for Code Review が特に得意なのは次のような問題です。

• string interpolation で組み立てた raw SQL
• unsafe な HTML rendering や危険な DOM insertion
• N+1 query を起こす ORM パターン
• 広すぎる except: 処理や握りつぶされたエラー
• 意図が伝わらない曖昧な naming
• maintainability を高めるべきコードベースでの type hints 欠如

どれも実務で頻出しやすく、しかも高コストになりがちなミスです。リポジトリ内の例があることで、汎用的なレビュー用プロンプトよりも判定基準を具体的に掴みやすくなっています。

意図的にカバーしていない領域

現在のルールセットは、あらゆるレビュー観点を網羅するほど広くはありません。たとえば、次の分野については大きな組み込みカタログがありません。

• authentication / authorization design
• concurrency hazards
• caching strategy
• API contract stability
• test quality
• infrastructure or deployment review

そのため、code-reviewer は「完全なレビューシステム」として期待して入れるのではなく、自分たちの主要リスクが、この skill の具体的なルール範囲と噛み合っているかで判断するのが適切です。

指摘数を増やすより、質の高い指摘を出させる方法

有用な出力がほしいなら、エージェントに「何でも指摘する」のではなく、一定基準を満たすものだけを報告させるのが有効です。たとえば次のように指定します。

Use the code-reviewer skill.
Only report issues that are:
- exploitable security risks
- likely production performance problems
- correctness bugs with user or data impact
- maintainability problems that materially reduce readability or safety

Do not comment on formatting unless it affects correctness or security.

こうしておくと、レビューがこの skill の本来の強みに沿いやすくなります。

部分的なコンテキストで code-reviewer を使う方法

毎回フルリポジトリを渡す必要はありません。次のような範囲でも、この skill は十分機能します。

• 単一の diff
• 1 つの controller と 1 つの template
• 1 本の ORM query path
• 1 つの関数と、その caller

ただし、security や N+1 パターンをレビューする場合は、少なくとも次が分かる程度の周辺コードを含めてください。

• user input がどこから入るか
• どう validation されるか
• query がどう組み立てられるか
• output がどう rendering されるか
• loop により query が繰り返し発行されるか

チーム向けの推奨出力フォーマット

チームで定着させたいなら、エージェントには次の形式で findings を返させると扱いやすいです。

Severity: Critical / High / Medium
Category: Security / Performance / Correctness / Maintainability
Rule: specific rule name
Location: file + line or function
Issue: one-sentence summary
Why it matters: concrete impact
Recommended fix: actionable change
Confidence: high / medium / low

この形にすると、code-reviewer usage の結果を PR 間・レビュアー間で比較しやすくなります。

code-reviewer skill の FAQ

すでに良いレビュー用プロンプトを書いているなら、code-reviewer を入れる価値はある？

通常はあります。特に、今のプロンプト運用にばらつきがある場合は有効です。最大の利点は「AI がより賢くなる」ことではなく、優先度の高いルールを明示した、再現性のあるレビュー枠組みを持てることです。すでに security-first のレビュー順と具体例を強く組み込んだプロンプトを運用しているなら、上積みは比較的小さくなります。

code-reviewer は初心者でも使いやすい？

はい。ソースファイルはざっと追いやすく、AGENTS.md には悪いコードと良いコードの対比が分かる例があります。初心者にとっては、レビュー支援ツールとしてだけでなく、レビュー用チェックリストとしても使えます。

code-reviewer は linters や static analyzers の代わりになる？

なりません。code-reviewer は deterministic な analyzer ではなく、推論を補助するための skill です。linters、SAST tools、type checkers、tests を置き換えるものではなく、補完するものです。特に、一般的な web / database リスクを含むコード変更に対して、文脈を踏まえた判断がほしいときに向いています。

どの言語やスタックと相性がいい？

例を見る限り、Python と JavaScript 系のコードにかなり寄っています。特に相性がいいのは次の領域です。

• SQL access layers
• web rendering flows
• ORM-backed applications
• frontend output handling

もちろん他の環境にも流用はできますが、組み込みの価値が最も強いのはこうしたパターン周辺です。

code-reviewer を使わないほうがいいのはどんなとき？

主な目的が次のいずれかなら、見送ったほうがいいです。

• formatting enforcement
• 広範な architecture assessment
• framework-specific compiler rules
• compliance evidence generation
• exhaustive language coverage

このような用途では、code-reviewer skill は狭すぎると感じやすいはずです。

code-reviewer は PR だけでなくフルリポジトリもレビューできる？

できます。ただし、得意なのはスコープを絞ったレビューです。フルリポジトリに対するレビューは、文脈の薄い指摘が大量に出やすくなります。最も効果が出やすいのは、変更ファイル、リスクの高いモジュール、あるいは機能単位でパスを切ってレビューするやり方です。

code-reviewer skill を改善する方法

まずはリスクの高い経路から当てる

code-reviewer の価値を高めるには、含まれているルールが効きやすいコードに絞って使うのが基本です。

• request handlers
• template rendering
• query builders
• ORM list endpoints
• error-prone integration boundaries

utility code 全体に無差別にかけるよりも、こうした箇所に当てたほうがシグナルははるかに良くなります。

データフローの文脈を明示する

ありがちな失敗は、入力から sink までの流れをエージェントが追えず、security review が弱くなることです。結果を改善したいなら、少なくとも次を明示してください。

• どの入力が user-controlled か
• どの field が database に届くか
• どの content が HTML に rendering されるか
• どの loop や resolver が repeated queries を起こしうるか

これだけでも、SQL injection、XSS、N+1 に関するルールの適用精度と confidence はかなり上がります。

ルールに紐づく根拠を出させる

code-reviewer の出力品質を上げる強い方法のひとつが、各指摘をルールに結びつけさせることです。

Use code-reviewer and tie each finding to the closest rule in AGENTS.md or rules/.
If no rule applies clearly, mark the finding as lower confidence.

これにより、ふわっとしたコメントが減り、レビューの信頼性も判断しやすくなります。

merge 可否に関わる基準で false positive を減らす

最初の実行結果がうるさすぎるなら、プロンプトを厳しくしてください。

• production impact がある問題だけに限定する
• blockers と suggestions を分ける
• 純粋な style コメントは除外する
• 具体的な fix path を必須にする

この調整を入れると、レビュアーがすぐ行動に移せる出力になりやすく、運用にも乗せやすくなります。

初回レビュー後に再実行する

2 回目のプロンプトとして有効なのは、単に「もう一度レビューして」ではありません。むしろ次のように指定するほうが効果的です。

Re-run code-reviewer on the updated diff.
Check whether the previous high-severity findings are actually resolved.
Then look for any newly introduced correctness or maintainability issues caused by the fixes.

これにより、修正の過程で生まれた新しい不具合や、見かけ上は直ったが本質的には未解決、というケースを拾いやすくなります。

チーム導入するなら慎重に拡張する

もし code-reviewer がチームのワークフローに組み込まれるなら、もっとも実用的な改善は、同じスタイルでルールファイルを追加していくことです。

• auth and authorization checks
• secrets handling
• CSRF/session safety
• caching misuse
• async/concurrency issues
• test coverage expectations

拡張する場合も、パターンは揃えるのが重要です。つまり、「なぜ重要か」「悪い例」「良い例」「impact level」をセットで書くことです。そうすれば、code-reviewer skill の分かりやすさを保ったまま、カバー範囲だけを広げられます。