rules-review

変更差分をそのリポジトリが明文化したルールに照らし、違反だけを検出する。「こうした方が良い」は出さない。

「良し悪しの意見」と「ルール違反」を混ぜると、レビューは読み手にとって取捨選択の作業になり、結局どれも直されない。指摘 1 件ごとに、根拠となるルールのファイル名を必ず添える。

disallowed-tools で Write / Edit を外している。判定と実装を同じターンでやると「指摘して、ついでに直して、直した結果を自分で承認する」が起きる。修正は別スキル・別ターンでやる。

引数:

• --pr: ベースブランチからの全差分をレビューする。省略時は未コミットの変更のみ
• --base <branch>: ベースブランチを明示する。省略時は既定ブランチを自動判定する

Step 1: 基準を決める

上から順に探し、最初に見つかったものを基準にする:

5 に落ちた場合は、## 基準 に「明文化されたルールなし」と明記したうえで、セキュリティと生成物の手編集に限って汎用観点で見る。それ以外の観点は出さない — 根拠のない好みの指摘が混ざると、この形式の信頼が一度で失われる。あわせて「rules を整備すると差分レビューが機能する」ことを 1 行添える。

複数の場所に rules がある場合は、より対象に近いもの(モノレポならサブディレクトリ側)を優先する。

Step 2: 差分を取る

# 既定ブランチの判定 (--base 未指定時)
git symbolic-ref --quiet refs/remotes/origin/HEAD 2>/dev/null | sed 's|.*/||'

取れなければ main → master の順に実在を確認する。

差分が無ければ「レビュー対象なし」で終わる。

Step 3: レビューする

変更されたファイルを自分で読む。 実装者の説明や PR 本文を source of truth にしない。書かれていない変更こそ見つけたいもの。

この骨格は変えない。中身は Step 1 で読んだ rules の実際の記述に置き換える。 rules に書かれていない観点を骨格に合わせて発明しない。

Step 4: 機械チェック

• リポジトリのチェックコマンド(make ci / npm run lint / go vet ./... など、実在するもの)を実行し、結果を第一の判断材料にする
• 変更ファイルに、正当化のない新規の TODO / FIXME / HACK が入っていないか
• シークレットらしき文字列(API キー、接続文字列、秘密鍵の PEM ヘッダ)が入っていないか

チェックコマンドが見つからなければ、実行せずに「未実行」と書く。

Step 5: レポートを出す

## コードレビュー結果

- 基準: .agents/rules/ | .claude/rules/ | AGENTS.md | 明文化されたルールなし
- 対象: <base>...HEAD | 未コミットの変更 (N ファイル)
- 機械チェック: `<コマンド>` PASS | FAIL | 未実行
- 判定: APPROVE | WARNING | BLOCK

[CRITICAL] path/to/file.go:42
Rule: security.md — ハードコードされたシークレットの禁止
Issue: API キーがリテラルで埋め込まれている
Fix: 環境変数から読む

[HIGH] ...

判定の基準:

違反が無ければ All checks passed. No violations detected. と、実際に見た観点を 1 行で返す。「何も出なかった」と「見ていない」を読み手が区別できるようにする。

原則

• 証拠を必ず添える。 file:line と該当箇所の逐語抜粋が無い指摘は出さない。裏が取れない懸念は指摘欄ではなく末尾の「notes」に隔離する
• 「見つけられなかった」を「違反なし」と書かない。 読めなかったファイル・判断できなかった箇所は、そう書いて残す
• テストが通っていることはルール準拠の証明にならない。 通ったかどうかと、ルールに違反しているかどうかは別の話
• rules に無い指摘をしたくなったら、指摘ではなく rules への追記を提案する。 そうしないとレビューが個人の好みの表明になり、次のレビューで基準が変わる