変更点を点検させるスキルを使う手順

結論

AIに書かせたものを、そのまま採用してはいけません。とはいえ、変更点を1行ずつ自分で追うのは骨が折れます。/code-reviewは、いまの変更をひととおり点検し、間違いと整理できる箇所を挙げる同梱スキルです。導入作業は要りません。使う習慣がないと、動いているように見えるだけの変更を抱え込むことになります。

何を見て、何を見ないのか

/code-reviewが対象にするのは「いまの変更」です。ブランチの、上流より先に進んでいるコミットと、まだコミットしていない変更をあわせて読みます。裏を返すと、変更が何もなければ報告するものもありません。

見るのは正しさの誤りと、既にある部品の再利用・単純化・効率といった整理の余地です。指摘には深刻度の印が付きますが、承認や却下の判定はしません。GitHubのアプリを入れなくても、ターミナルの中だけで完結します。

似た名前の/simplifyは整理専門で、間違い探しはしません。不具合を見つけたいときは/code-reviewの側です。

待たずに済む作りになっている

点検は背景で動くサブエージェント（別の作業役）が担当し、専用の作業領域を持ちます。あなたの会話を占領しないため、待っている間もふだんの作業を続けられます。結果が出ると、会話に指摘が届くという流れ。

指摘の細かさは、労力の設定で変えられます。控えめな設定では自信のある指摘だけに絞られ、誤検出が減ります。強い設定では網を広く張るかわりに、確信の薄い指摘も混じります。

前提条件

• 点検したい変更が、コミット済みか作業ツリーに存在すること
• /code-reviewはメッセージの先頭で入力すること
• リポジトリのCLAUDE.mdは点検にも読み込まれます。書いてある方針が指摘の内容に影響します

手順

1. 変更を加えたセッションで/code-reviewと入力します
2. ほかの場所を見せたいときは、続けて対象を書きます。ファイルのパス・PR番号・ブランチ名・main...my-featureのような範囲指定が使えます
3. 結果が届くまで、別の作業を進めて構いません
4. 届いた指摘を読み、直すものを選びます。そのままClaudeに修正を頼めます
5. 自分で選ばずまとめて直させたい場合は--fix、PRに行単位のコメントとして残したい場合は--commentを付けます

検証の考え方

指摘が妥当かどうかは、指摘された行を自分で開いて確かめるのが基本です。深刻度の印は優先順位の目安であり、正しさの保証ではありません。

--fixを使ったときは、変更後のコードを必ず読んでください。背景で走った点検の修正は、セッションの巻き戻し（/rewind）の対象外です。取り消したいときはGitで戻します。この違いは、実際に取り消そうとした場面で初めて気づくと厄介です。

限界と注意

すべての不具合が見つかるわけではありません。控えめな設定では見落としが増え、強い設定では確信の薄い指摘が増えます。どちらの設定でも、最終的に採否を決めるのは人の側です。

もう1点、点検はあくまで「変更点」に対して行われます。変更していない箇所に元からある問題は、この方法では出てきません。

学習上の注意

指摘をすべて直せば良いコードになる、という道具ではありません。指摘の理由を読んで、納得できるものだけを取り入れてください。理由が分からない指摘は、直す前にClaudeに説明を求めると、次に同じ書き方をせずに済みます。