Claude CodeとGit・PRレビュー

10秒でいうと

コミットもPRも任せられます。ただし1コミット1目的を守らせるのはこちらの仕事です。
レビューは、実装したのと同じ場所でやらせないでください。

No.39で「巻き戻しはGitの代わりにならない」と書きました。ここではGitそのものの話をします。

Claude CodeはGitを直接扱う
コミットメッセージを任せる
レビューを任せる
CIに組み込む
見積書の仕事はここで完成する
つまずきポイント
まとめ
次に読む

Claude CodeはGitを直接扱う

ステージング、コミットメッセージの作成、ブランチの作成、PRの作成。全部できます。

いまの変更をコミットしてください。1コミット1目的で、
複数の目的が混ざっているなら分けてください。

1コミット1目的で、という一言を毎回書くのがコツです。書かないと、その日にやったことが全部1つのコミットになります。

本ガイドのリポジトリもこの規約で回していて、CLAUDE.md に書いてあります。そして実際に守られています。これは「たぶん従う」で足りる種類のルールだからです（No.41）。

コミットメッセージを任せる

差分を読んでメッセージを書かせると、自分で書くより正確なことがよくあります。変更の全体を見ているためです。

ただし、なぜそうしたかは書けません。差分には理由が写っていないからです。

だから、こういう頼み方になります。

コミットメッセージを書いてください。
本文には「何を変えたか」ではなく「なぜ変えたか」を書いてください。
理由は次のとおりです：（ここに書く）

何をしたかはClaudeが読める。なぜしたかは人が渡す。この分担が、実際いちばんうまくいきます。

レビューを任せる

第3章のNo.22で「実務役とレビュー役は分ける」と書きました。Gitでは、これが具体的にできます。

同じ会話でレビューさせない。実装した本人に「合っていますか」と聞くと、たいてい合っていると答えます。

やり方は3つ。

別の会話で見せる。/clear してから差分を読ませる。経緯を知らない状態で読みます。

組み込みのスキルを使う。/code-review が差分を読んでレビューします。

サブエージェントに任せる。No.23の形です。読む道具しか渡さないレビュー担当を作れば、間違って直されることもありません。

---
name: reviewer
description: 差分をレビューする。実装が終わったあとに使う
tools: Read, Grep, Glob
---

差分を読んで、次の観点で指摘してください。
・エラー処理の漏れ
・テストが要る変更なのに追加されていない箇所
・命名が周囲と揃っていない箇所

直さないでください。優先度順に指摘だけを返してください。

tools を読むだけに絞るのが要点です。第3章から一貫している「範囲を先に区切る」がここでも効きます。

CIに組み込む

公式ドキュメントによれば、GitHub ActionsやGitLab CI/CDでPRレビューや課題の仕分けを自動化できます。PRごとに自動でレビューを付ける仕組みもあります。

Slackから使う形もあって、バグ報告をSlackで投げるとPRが返ってくるという流れが作れます。

ここまで来ると、第4章のCoworkの定期実行と同じ構図になります。見ていない時間に動くものは、実行ではなく報告を出させる。PRを自動で作るのはよいですが、マージは人が押してください。

見積書の仕事はここで完成する

第2章から追ってきた例が、この章で最後の形になります。

第2章：PDFを1枚ずつ会話に貼る
第4章：フォルダを渡して、Excelができる
第5章：手順をスキルにして、CIで毎週回す

最後の形では、毎週月曜に自動で一覧表ができて、差分が報告されるところまで行けます。ただし送信と確定は人が押す。これはNo.31から変わりません。

やってみよう：レビュー専用のサブエージェントを作る（5分）

プロンプト
“`
このプロジェクト用のレビュー担当サブエージェントを作ってください。

・.claude/agents/ に置く
・tools は読むだけに絞る
・このリポジトリで実際に見つかりそうな観点を3つ選ぶ
・「直さない。指摘だけ」を指示に入れる
・作る前に中身を見せてください
“`

作ったら、何か変更してから呼んでみてください。

期待される結果：レビュー担当ができ、差分を読んで指摘だけ返す。

うまくいかないとき：観点が一般論なら、「このリポジトリで過去に起きた種類の問題」を聞いてから作らせてください。具体的な観点のほうが役に立ちます。