ktaroabobon rules-review
変更差分をそのリポジトリが明文化したルールに照らし、違反だけを検出する。「こうした方が良い」は出さない。
「良し悪しの意見」と「ルール違反」を混ぜると、レビューは読み手にとって取捨選択の作業になり、結局どれも直されない。指摘 1 件ごとに、根拠となるルールのファイル名を必ず添える。
disallowed-tools で Write / Edit を外している。判定と実装を同じターンでやると「指摘して、ついでに直して、直した結果を自分で承認する」が起きる。修正は別スキル・別ターンでやる。
引数:
--pr: ベースブランチからの全差分をレビューする。省略時は未コミットの変更のみ--base <branch>: ベースブランチを明示する。省略時は既定ブランチを自動判定する
Step 1: 基準を決める
上から順に探し、最初に見つかったものを基準にする:
| 順 | 場所 | 扱い |
|---|---|---|
| 1 | .agents/rules/ |
配下を全部読む(README.md 含む) |
| 2 | .claude/rules/ |
同上 |
| 3 | docs/rules/ / .github/rules/ |
同上 |
| 4 | AGENTS.md / CLAUDE.md / CONTRIBUTING.md |
規約に相当する節だけを基準として抜き出す |
| 5 | どれも無い | 明文化されたルールが無いと報告する(下記) |
5 に落ちた場合は、## 基準 に「明文化されたルールなし」と明記したうえで、セキュリティと生成物の手編集に限って汎用観点で見る。それ以外の観点は出さない — 根拠のない好みの指摘が混ざると、この形式の信頼が一度で失われる。あわせて「rules を整備すると差分レビューが機能する」ことを 1 行添える。
複数の場所に rules がある場合は、より対象に近いもの(モノレポならサブディレクトリ側)を優先する。
Step 2: 差分を取る
# 既定ブランチの判定 (--base 未指定時)
git symbolic-ref --quiet refs/remotes/origin/HEAD 2>/dev/null | sed 's|.*/||'
取れなければ main → master の順に実在を確認する。
| 引数 | コマンド |
|---|---|
| なし | git diff --name-only HEAD |
--pr |
git diff --name-only <base>...HEAD |
差分が無ければ「レビュー対象なし」で終わる。
Step 3: レビューする
変更されたファイルを自分で読む。 実装者の説明や PR 本文を source of truth にしない。書かれていない変更こそ見つけたいもの。
| 優先度 | カテゴリ | 見るもの |
|---|---|---|
| CRITICAL | Security | シークレットの混入、認可・テナント分離の漏れ、入力検証の欠落、危険なコマンド実行 |
| CRITICAL | Architecture | 依存方向の逆流、レイヤ・境界の逸脱、生成物の手編集 |
| HIGH | Coding Style | 明文化された規約からの逸脱、エラーハンドリングのパターン逸脱 |
| HIGH | Simplicity | 1 箇所でしか使わない抽象化、将来を前提にしたオプション、不要な新規依存 |
| MEDIUM | Tests | ルールが求めている範囲のテストが無い、壊れやすいテスト |
この骨格は変えない。中身は 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] ...
判定の基準:
| 判定 | 条件 |
|---|---|
| APPROVE | CRITICAL / HIGH なし |
| WARNING | MEDIUM のみ |
| BLOCK | CRITICAL / HIGH がある、または機械チェックが FAIL |
違反が無ければ All checks passed. No violations detected. と、実際に見た観点を 1 行で返す。「何も出なかった」と「見ていない」を読み手が区別できるようにする。
原則
- 証拠を必ず添える。
file:lineと該当箇所の逐語抜粋が無い指摘は出さない。裏が取れない懸念は指摘欄ではなく末尾の「notes」に隔離する - 「見つけられなかった」を「違反なし」と書かない。 読めなかったファイル・判断できなかった箇所は、そう書いて残す
- テストが通っていることはルール準拠の証明にならない。 通ったかどうかと、ルールに違反しているかどうかは別の話
- rules に無い指摘をしたくなったら、指摘ではなく rules への追記を提案する。 そうしないとレビューが個人の好みの表明になり、次のレビューで基準が変わる