Review Before Commit

---
name: review-before-commit
description: commit を提案する直前に回す検査。対話でのみ述べて記録に入れ忘れたものを洗い出し、文脈を持たない読み手が読めるかを参照・時点語・件数の3軸で検査する。公開リポジトリなら、コミットメッセージの規約・staging に混ざった未追跡ファイル・履歴として公開される情報も同じ1本で検査する。staging 内容とコミットメッセージを提示する前に使用（push 前の検査は review-before-push）。
---

# commit 直前の検査

**読み手は「文脈を持たない次のセッションの AI」である。** 書いた本人には解決できてしまう参照が、ここで落ちる。

🔴 **冒頭で1つだけ判定する: 対象は公開リポジトリか、非公開か。** ⇒ **公開なら、下の「公開リポジトリのときに追加で回す」節まで含めて、この1本で回す。** ⭐ **判定は最初の1回だけで、手順ごとに「これは公開向けか」を考えない**——**判断の場面を消すための構成である。**

**この Skill は手順だけを持つ。** **なぜ検査するかの一般形は `01_ai-driven-dev-strategy.md`「外に出る直前に検査を挟む（非可逆な操作のゲート）」**にあり、**このリポジトリ固有の規約は `CLAUDE.md`** にある。⇒ **どちらも正本で、この Skill はその実装である。**

## 前提思想

- **検査は通過判定ではない。** 指摘は列挙して人間に渡す。致命的でなければ直さず記録する、という選択が常にある。
- **検査そのものが、部分適用で「通過」しうる。** 落ち方は2通りある——**検査項目の一部を飛ばす**（3軸のうち2軸だけ当てる）と、**検査対象の一部を飛ばす**（2ファイルのうち1ファイルだけ見る）。⇒ **どちらも明示的に宣言してから始める。**
- **対象は「自分が編集した範囲」ではない。** 今回触っていない箇所でも、次のセッションの開始に要るなら読む。

## モード

| モード | 発動 | 振る舞い |
|--------|------|---------|
| **検査（既定）** | commit を提案しようとした瞬間 | 下の手順を上から順に回し、検出物を一覧で出す |
| **再検査** | 前回の検査の後にさらに編集した場合 | **前回の検査後に書いた分を対象に、同じ手順を回す**（⚠️ 前回「通った」ことは今回の根拠にならない） |

## 確度ラベル

検出物には `[Fact]`（実測した）／`[Judgment]`（読んで判断した）／`[Assumption]`（確かめていない）を付ける。**「たぶん解決する」を `[Fact]` として報告しない。**

## 手順

### 1. 対話にのみ在るものを洗い出す

このセッションで**対話でのみ述べて、まだ `.md` に入っていない**ものを列挙し、1件ずつ「入っている／入っていない」を判定する。

- ⚠️ **特に見るもの: 「後で書きます」「レトロで扱います」「次のセッションで」と言ったもの。** ⇒ **そう言ったこと自体が、記録した気にさせる。**
- ⚠️ **裁定・訂正・数値・人の逐語**は落ちやすい。**提案しただけで採用されなかったものは、落ちてよい**（区別して報告する）。
- **判定は grep で行う**——記憶で「書いたはず」と答えない。
- 🔴 **見る対話の範囲を、先に宣言する**——**次の手順で宣言するのはファイルの範囲だけなので、宣言しないと「差分に関係する対話だけ見る」に縮む。**
- ⭐ **機械的に拾えるやり方: 人間の発言から、打ち返しに使われた半角の ID を拾い、その ID で記録を引いて突き合わせる**（**ID を振る規約が、この検査を成立させている**）。⚠️ **限界2つ**: **`1` 数字を含まない ID や、案の ID ではなく問いの ID で答えられた場合は拾えない `2` 拾った ID が「裁定」か「単なる言及」かは機械では分けられない。** ⇒ **その2つは人間の確認に回す。**

### 2. 検査対象を宣言する

- **今回の diff で触ったファイル**
- ＋ **それらを指しているファイル／それらが指しているファイル**
- ＋ **次のセッションの入口になるファイル**（制御plane・記録の開始点）

⇒ **この3つを列挙してから検査に入る。** 対象を宣言しないと、後から「そこは見ていなかった」が出る。

### 3. 3軸をすべて当てる

| 軸 | 見るもの | 落ちている例 |
|---|---|---|
| **参照** | リンク・見出し名・ID・「あのファイル」「上記」「下記」 | 実在しない見出しを指す／位置語で指した先が、自分の挿入で動いた |
| **時点語** | 「次」「現在」「まだ〜していない」「予定」 | 読まれる時点では既に済んでいる断定形／どのセッションを指すか決まらない |
| **件数・範囲** | 「N 件」「`A`〜`E`」「N 本」 | 正本から数え直せる値を別の行に書いた（**編集のたびに壊れ、壊れたことが読んでも分からない**） |

⚠️ **3軸のうち1つでも当てていないなら「通った」と報告しない。**

🔴 **集計を報告するときは、独立に取れる既知の値との照合を併記する**——**「N 件を走査した」だけでは、走査そのものが壊れていても通る。** ⇒ **別の手段で取れる値（ファイル数・見出し数・前回の集計）と突き合わせ、一致／不一致を書く。** ⭐ **報告文を見れば外から判定できる形にする。**

### 4. 出力する

検出物を一覧にして、**直すか・記録して残すか**を人間に裁定させる。⚠️ **勝手に直さない**——AI の指摘は提案であって、自動適用しない。

## 公開リポジトリのときに追加で回す

**公開リポジトリの履歴は、push した時点で永久に公開される。** ⇒ **diff だけでなく、メッセージ・日時・author・staging の中身が、そのまま読まれる。**

🔴 **この節が要る理由は「漏れるから」ではなく「直すコストが跳ね上がるから」である。** **push 前に見つけても直せるが、履歴になった後は `amend` か rebase になる**——**小さく commit する運用と組み合わさると、跨る確率が高い。**

- **commit の瞬間にしか安く直せないものがある**——**メッセージ／staging の中身／author。**
- **commit date は、commit した瞬間に確定する。** ⇒ **push を遅らせても稼働時間の露出は減らない**（遅らせて効くのは操作ミスと誤公開だけ）。**ここで止められるのは「何を・どう書くか」であって、日時ではない。**

### 5. コミットメッセージを検査する

- **何をしたかを1行で書く。理由を書かない**——**理由は判断の記録側、課題は課題一覧側に置く。** 🔴 **git 履歴は正本ではなく複製であり、意味を載せると二重管理になって必ず片方が腐る。**
- ⚠️ **発火の合図: メッセージに理由を書きたくなった瞬間。それが判断の記録へ起票する合図である。** ⇒ **「後で書く」と言わずに、その場で起票する。**
- **メッセージ自体の機微を見る**——**実名・メールアドレス・絶対パス・内部 URL・チケット ID・依頼者や案件の名前。**
- **`-m` を複数指定して渡す**（件名と付記を別の `-m` にする）。⚠️ **複数行の文字列を1つの引数として組み立てない**——**引用符法を選ぶ場面が生じ、literal が混入する失敗モードに到達できてしまう。**

### 6. staging の中身を1件ずつ提示する

- 🔴 **`git add -A` を使わない**——**未追跡ファイルを無検査で取り込むため。**
- **staging に入るファイルを列挙し、意図しないものが無いかを人間に見せる**——**下書き・作業メモ・一時ファイル・別の作業の残骸。**
- ⚠️ **`.gitignore` されているものは diff に出ない。** ⇒ **「差分がきれい」は「混入が無い」を意味しない**——**追跡下に入る瞬間を見る。**

### 7. 履歴として公開されるものを確認する

- **author**（名前・メールアドレス）が意図した値か。
- **この commit が、稼働の傾向を露出させないか**——**個々の記述が許容範囲でも、時系列で累積すると像を結ぶ。**
- **判定基準は「内部か外部か」ではなく「書き手の生活・稼働の記録か、内容についての判断の記録か」。**

## Output Format

```
## 対象（公開 / 非公開）
## 対話にのみ在るもの
| ID | 内容 | 判定 |

## 検査対象（宣言）
- 触ったファイル / それを指すファイル / 入口

## 3軸の結果
| 軸 | 結果 | 検出物 |

## 公開リポジトリのとき（非公開なら「対象外」と1行書く）
- staging（1件ずつ）
- コミットメッセージ案（件名 / 付記）— 理由を書いていないか / 機微は無いか
- 履歴としての露出（author / 稼働の傾向）

## 提案
- 直す: …
- 記録して残す: …

## 承認のお願い（commit のみ。push は別に伺う）
- 末尾に `y`（実行）／`n`（差し戻し）を置く
```

## この Skill の受入基準（AC — 機能したと言える観測可能な条件）

1. **対象が公開か非公開かを、検査を始める前に宣言した**
2. **対話にのみ在るものを、grep で判定して列挙した**（記憶で答えていない）
3. **検査対象を、検査を始める前に列挙した**
4. **3軸すべてを当てたことが出力から読み取れる**（部分適用でないこと）
5. **検出物を勝手に直していない**——直すかどうかは人間が決めた
6. **検出ゼロのときも、何を見てゼロだったかが読み取れる**
7. **公開リポジトリのときは、staging を1件ずつ列挙し（`git add -A` を使っていない）、メッセージに理由が入っていないことを確認し、メッセージの機微を名指しで検査した**
8. **commit の承認だけを求めた**（push を同じ文で承認させていない）
9. **承認を求める文が、半角小文字1文字（`y`／`n`）で打ち返せる形で終わっている**——**検査結果やメッセージ案で終わると、何を答えるのかが読み手の推測になる**

## 運用規律

- **規律の本体は `01`「外に出る直前に検査を挟む」と `CLAUDE.md`。** この Skill が持つのは手順だけで、同じことを二重に書かない。
- 🔴 **この1本で公開・非公開の両方を覆う。** ⚠️ **他の Skill を呼ぶ前提を持たない**——**自足させることで、呼び出す本数を増やさない。**
- **push 前の検査は `review-before-push`**（到達状態・確度ラベル・不変条件での測定。公開なら読み手・機微・版が加わる）。
- **環境依存の値（パス・ホスト名・バージョン）をこの Skill に書かない。** 実行環境の記録側に置く。
- **この Skill は commit の可否を判定しない。** 判定するのは人間である。