# Rules Review

> 変更差分をリポジトリの rules に照らしてレビューし、ルール違反だけを重大度つきで検出する。「コードレビュー」「差分レビュー」「実装をレビュー」「rules に照らして確認」「PR の差分を見て」時に使用。.agents/rules/ → .claude/rules/ → AGENTS.md / CLAUDE.md の順に基準を自動探索するので、オンボーディング済みでないリポジトリでも動く。好みの改善提案は出さない。検出のみで修正はしない。

- Skill: `ktaroabobon/rules-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ktaroabobon/rules-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ktaroabobon/rules-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: ktaroabobon (https://skillmd.com/u/ktaroabobon)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/ktaroabobon/rules-review

---


# 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: 差分を取る

```bash
# 既定ブランチの判定 (--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: レポートを出す

```md
## コードレビュー結果

- 基準: .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 への追記を提案する。** そうしないとレビューが個人の好みの表明になり、次のレビューで基準が変わる