code-review-and-quality

取り込む前のあらゆる変更に使う、レビューの手引きです。本文の「使うとき」は、変更を取り込む前、機能を実装し終えたあと、別のエージェントやモデルが書いたコードを評価するとき、リファクタリングのとき、バグを直したあと（修正と回帰の試験の両方を見る）の 5 つです。

説明文は、差分やプルリクエストのレビューを頼まれたら、差分が会話に貼り付けられただけでも使え、と書いています。書いたのが自分でも、ほかのエージェントでも、人でも同じ扱いです。

見る軸

5 つ

指摘に付ける重さの札

5 種

SKILL.md（2026-10-23 時点）

20,976 バイト

承認の基準は「全体が良くなるか」

本文は承認の基準を先に置いています。完璧でなくても、コードの全体の健康を確実に良くするなら承認せよ、というものです。

自分ならこう書く、という理由で止めるな、とも書いています。プロジェクトの決まりに従っていて全体が良くなるなら通す、が出発点です。

5 つの軸

• 正しさ仕様どおりか。null・空・境界値、エラーの経路、off-by-one や競合
• 読みやすさと単純さ名前、入れ子の三項演算子、もっと少ない行でできないか
• 設計既存の型に沿うか、依存の向き、複雑さを減らしたか移しただけか
• セキュリティ入力の検証、秘密情報、認可、SQL のパラメータ化、外部のデータを信用しない
• 性能N+1、上限の無い取得、ページ送りの欠け、余計な再描画

読みやすさの軸には「100 行で足りるところを 1000 行で書くのは失敗」「3 つ目の用途が来るまで汎用化しない」が入っています。関係の無い処理の流れに条件分岐を継ぎ足すのは、細かい指摘ではなく設計の匂いとして扱え、という項目もあります。

「移しただけ」を見抜く

設計の軸でいちばん特徴的なのは、リファクタリングが複雑さを減らしたのか、移しただけなのかを問う項目です。読み手が抱えておく概念の数を数え、それが変わらないなら「きれいになった」とは言わない、という基準です。

抽象を磨くより消すほうを選べ、とも書いています。指摘するときは問題だけでなく直し方を名前で示せ、として、構造の直し方を 8 つ挙げています。条件の連鎖を型付きのモデルや振り分けに置き換える、重複した分岐をまとめる、橋渡しをするだけの包みを消す、などです。

変更の大きさの目安

差分の大きさだけでなく、ファイルの大きさも見ます。1 つのファイルで合計約 1000 行は点検の目安で、上限ではない、という書き方です。分け方は 4 つ（積み重ね・ファイルの組ごと・共通部分から先に・機能の縦の切れ目）で、リファクタリングと機能の追加は別の変更に分けよ、としています。

レビューは 5 段で進める

1. 文脈をつかむ何を達成したい変更か、どの仕様や作業に当たるか
2. 試験を先に読む試験は意図と網羅を表す。振る舞いを見ているか
3. 実装を読む変わったファイルごとに 5 つの軸で
4. 指摘を分類する重さの札を付け、効き目の大きい順に並べる
5. 確かめを確かめる何の試験を流したか、ビルド、手での確認、画面なら前後の比較

試験が回帰を捕まえるかは、読まずに試す

2 段目の「コードが変わったら試験は回帰を捕まえるか」には、読んで答えるな、実験で答えよ、と書かれています。変更が足した条件を 1 つ反転させ（否定を外す、&& を || にする）、試験を流し、写しからファイルを戻します。

反転させても試験が緑のままなら、それ自体が指摘になります。欠けている試験の場面を名指しで挙げよ、という指示です。

重さの札を付ける

並べる順は、正しさとセキュリティが先、次に構造の後退と見落とした単純化、残りはその後です。構造の問題が 1 つと細かい指摘が 10 個なら、構造の問題がレビューそのものだ、と本文は書いています。

遠慮せずに、数で言う

「LGTM」だけで通さない、本物の問題を「小さな懸念かも」と和らげない、迎合はレビューの失敗の形だ、と書かれています。問題は可能なら数で言え、として「この N+1 は一覧の 1 件ごとに約 50ms 足す」のような言い方を勧めています。

一方で、作者が全体の文脈を持ったうえで反対するなら、その判断に従え、とも書いています。指摘はコードに向け、人に向けない、という線引きです。

依存の追加と更新もレビューの一部

依存を足す前に、今の構成で足りないか、大きさ、保守されているか、既知の脆弱性（npm audit）、ライセンスの 5 つを確かめます。更新は、変更履歴を読む、1 つの変更で 1 つの依存、試験に判断させる、推移的な依存とロックファイルの差分を見る、ロックファイルを手で直さない、の 5 つです。

• 規約と仕様を分けて並行で見たい2 つの軸を別のサブエージェントで走らせる側
• 文脈を持たない別のレビュー役に出したい渡す文脈の組み立て方が中心の側
• 受けた指摘にどう応じるか指摘を受ける側の作法
• 性能の問題を測って直したい測る・直す・測り直すの側

軸を分けて並行に走らせたいなら

このスキルは、5 つの軸を 1 人のレビュー役が順に見る手引きです。規約と仕様の 2 つを別のサブエージェントで並行に見させ、片方の指摘がもう片方を隠さないようにしたいなら、mattpocock の code-review のほうが目的に合います。

本文にも「別のモデルに見させる」型は載っています。モデル A が書き、モデル B が正しさと設計を見て、A が直し、最後は人が決める、という流れで、レビュー役への指示の例も付いています。ただ、サブエージェントの出し方や渡す文脈の組み立てまでは書かれていないので、そこが要るなら requesting-code-review と組み合わせることになります。

指摘を受ける側の作法が知りたいなら

このスキルが扱うのは見る側です。受けた指摘をどう確かめ、どこで押し返すかは receiving-code-review が扱っています。

性能を本格的に調べたいなら

性能の軸は N+1 や上限の無い取得などの点検にとどまり、詳しい計測と最適化は performance-optimization を見よ、と本文が案内しています。セキュリティの軸も同様に、詳しくは同じリポジトリの security-and-hardening を見よ、と書いています。

SKILL.md には、外部への通信の記述はありません。シェルで動かすのは、試験の実行と、依存の点検の例として挙がる npm audit です。

使われなくなったコードは、聞いてから消す

リファクタリングや実装のあとに、使われなくなったコードを探して一覧にし、消してよいかを尋ねよ、と書かれています。黙って消すな、迷ったら聞け、という指示なので、レビューの途中で確認を求められることがあります。

名指しされる先と点検表は、このフォルダの外にある

本文は同じリポジトリの security-and-hardening、performance-optimization、constraint-driven-development を名指しします。末尾の参考は ../../references/security-checklist.md と ../../references/performance-checklist.md で、どちらもリポジトリの直下にあり、スキルのフォルダの外です。

スキルのフォルダには SKILL.md しかありません（同梱 0 件、2026-10-23 時点）。このスキルを 1 件だけ入れると、名指しされた先も点検表も手元に無いことがあります。

人のチームの決まりも混ざっている

レビューの速さ（1 営業日以内に返す、これは上限で目標ではない）、意見が割れたときの優先の順（技術的な事実とデータ、スタイルガイド、設計の原則、一貫性）、「後で直す」を受け付けない、といった節があります。これらは人のチームの運用の決まりで、エージェントに 1 回のレビューを頼む場面ではそのまま当てはまらない部分です。

「阻止の候補」は、悪化させるときだけ必須に上げる

確かめの節の最後に、阻止の候補が 5 つ挙がっています。複雑さを移しただけのリファクタリング、分けずにファイルを大きくする変更、共有のモジュールに入れた機能の処理、既存の正の補助関数のほぼ写し、不変条件を隠す黙った代替、です。

それぞれ、より単純な設計を示して表に出し、構造を実際に悪くしているときだけ必須に上げよ、という扱いです。既存のコードに当てると候補が多く出やすいので、どこまでを今回の範囲にするかを先に決めておくと扱いやすくなります。

ライセンス

リポジトリのライセンスは MIT です。

自動で呼ばれますか

手で呼び出す指定は付いていません。説明文に、取り込む前のあらゆる変更、自分やほかのエージェントや人が書いたコードの評価、差分やプルリクエストのレビューを頼まれたとき、と呼びどころが並んでいます。公開元の README は、Claude Code に組み込みの /review と名前がぶつかるので、プラグインとして入れたときは /agent-skills:review の形で呼ぶよう案内しています（2026-10-23 確認）。

札の無い指摘はどういう扱いですか

札の無い指摘は「必須」の扱いで、取り込む前に直す必要があります。任意の提案には Optional や Consider、細かい好みには Nit を付けて、作者がすべての指摘を必須と受け取って時間を使わないようにする、というのが札の狙いです。本文のレビュー役への指示の例では、Critical・Required・Optional・Nit の 4 つで分けさせています。

AI が書いたコードは軽く見てよいですか

本文は逆の立場です。よくある言い訳の表に「AI が生成したコードはたぶん大丈夫」があり、AI のコードは検査を減らすのではなく増やす必要がある、間違っていても自信があって尤もらしいから、と返しています。「試験が通ったから良い」も、試験は必要だが十分ではなく、設計やセキュリティや読みやすさの問題は捕まえない、と退けています。

対応しているエージェントはどれですか

公開元の README が、Claude Code（推奨と明記）と Codex のそれぞれに入れ方を案内しています（2026-10-23 確認）。README はほかに Cursor・Gemini CLI・GitHub Copilot などへの入れ方も載せていますが、当サイトが表示しているのは Claude Code と Codex の 2 つです。