Review Before Push

---
name: review-before-push
description: push する直前に回す検査。別環境で clone / pull して再開する視点で到達状態を判定し、確度ラベルが今も正しいかを読み直す。公開リポジトリなら、初めて読む人間の視点・機微情報・版（タグ）の要否も同じ1本で検査する。push の承認を求める前に使用（commit 直前の検査は review-before-commit）。
---

# push 直前の検査

**push は外に出る操作である。** commit はローカルに留まり `amend` / `reset` で巻き戻せるが、**push は戻すのに履歴へ revert を積むか force push が要る**（別マシンに clone があれば整合も壊れる）。⇒ **検査の重さは、操作の非可逆性に合わせる。**

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

**この Skill は手順だけを持つ。** **一般形は `01_ai-driven-dev-strategy.md`「外に出る直前に検査を挟む（非可逆な操作のゲート）」、リポジトリ固有の規約は `CLAUDE.md`** にある。

## 前提思想

- **判定するのは到達状態であって、作業範囲ではない。** 「どこまで読んだか」ではなく「**次のセッションが開始できるか**」。
- **書いた本人には解決できてしまう参照が、ここでだけ落ちる。** ⇒ **自分が持っている文脈を外して読む。**
- **未 push の commit は、時間差の再点検から漏れる。** 書かれた時点と公開される時点がずれ、**その分だけ確度ラベルが古びる。**

## モード

| モード | 発動 | 振る舞い |
|--------|------|---------|
| **検査（既定）** | push の承認を求めようとした瞬間 | 下の手順を回し、検出物を一覧で出す |
| **再検査** | 検査後にさらに commit を積んだ場合 | **積んだ分を対象に回す**（前回の結果は今回の根拠にならない） |

## 手順

### 1. 到達状態を判定する

**問い: 別のマシンで0から `git clone` した AI が、コンテキストを失わずに次のセッションを開始できるか。**

- **入口から読み始める**——制御plane と、記録の「次にやること」。**そこから着手先が一意に決まるか。**
- **典型的な壊れ方3つを当てる**: `1` **参照先が解決できない**（ID・リンク・「あのファイル」）`2` **「次」「現在」「まだ〜していない」がいつを指すか決まらない** `3` **件数・範囲が実態と合っていない**
- 🔴 **通過条件を持たない検査は、部分適用でも「通過」を申告できる。** ⇒ **何を見たかを列挙してから判定する。**

### 2. 構造を変えたなら、その実体を指す行を全部探す

ファイルを新設・移設・削除・改名したなら、**それを指している他の記述を grep する。** ⇒ **実体の置き場所を指す行は、構造を変えるたびに必ず腐る。**

🔴 **「〜で探すこと」という検索語つきのポインタは、その検索語で実際に引けるかを確かめる。** ⚠️ **引き方を指定しないと検査が壊れる**——**検索語は「バッククォートを付けたまま」と「外した版」の両方で引き、どちらかが1件以上ヒットすれば到達可能とみなす**（**参照側と到達先で記法の有無が揃っていないため**）。⭐ **両方で引けば「外すかどうか」の判断の場面が消える。** 📌 **バッククォートは Markdown の記法であり、検索・正規表現・シェルのいずれでも別の意味を持つ**——**記法としての印と、データとしての文字が混ざる。**

### 3. 確度ラベルを読み直す

この push に含まれる `[Fact]` / `[Judgment]` / `[Assumption]` / `[To Be Verified]` と、「N 回の観測」「未検証」を読み直す。

- ⚠️ **同じセッションの後半の作業が、前半の記録を偽にしていることがある。**
- ⚠️ **前提を実測したことは、結論を実測したことではない。**
- **偽になっていたら、旧記述を「証跡」として残し、上に訂正を置く**（消さない）。

### 4. 到達は値ではなく不変条件で測る

- **remote の hash は、自分が出した証拠にならない**——他者の push でも remote は進む。
- ⇒ **`git status -sb` の ahead/behind と、`git branch -r --contains <自分の hash>` で測る。**
- **記録には hash・本数・到達点を書かない**——`git log` から数え直せる値だから。

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

**公開は、外に出るだけでなく、読み手が変わる操作である。** 内輪の文脈を持たない読み手が、初めてこの木を開く。

- **公開物は「配布する新しい実体」である。** ⇒ **実体が変われば版が動く。**
- **機微は、消し忘れれば漏れる。** ⇒ **クレンジング（消す）ではなく抽出（取る）を既定にする**——**失敗の方向が安全側に倒れる。**

### 5. 初めて読む人間の視点

- **入口（README・読み順）から入って、迷わず目的の章に着けるか。**
- **内輪の語が漏れていないか**——**対話でだけ使う呼称（愛称）／役割名と実体名の混同／その場でだけ通じる ID や記号。**
- **読者に説明コストを課す記号・略語**が、定義なしで出ていないか。
- **役割名で書くべき箇所が、著者環境の実体名になっていないか**（読み手ごとに置き場所が違うものは、役割名でなければ成立しない）。

### 6. 機微検査

**全 git 追跡ファイルが対象**（push すれば全て可視になるため）。

- **メールアドレス／実名／認証情報・トークン／絶対パス／内部 URL・チケット ID**
- **書き手の生活・稼働の記録**——**個々の記述が許容範囲でも、時系列で累積すると稼働の傾向が像を結ぶ。**
- **実プロジェクトの情報**（ドメイン・外部サービスのページ ID・体制・納期）。
- ⚠️ **判定基準は「内部か外部か」ではなく「書き手の生活・稼働の記録か、内容についての判断の記録か」。**
- 🔴 **パターンは誤検出を出す。hit の中身を必ず目で確かめる。** ⚠️ **実例: 認証情報を探す `sk-` が、`task-name` という語の中に当たる。** ⇒ **「件数が0でない」を検出と読まない。** ⭐ **逆向きも同じ**——**0件だったことを報告するなら、何のパターンを何に当てたかを書く。**

### 7. 版（タグ）の要否を申告する

- **適用範囲のファイルを触ったかを実測する**（ガイド本体・制御plane・Skill・セットアップ手順）。
- **触ったなら MAJOR / MINOR / PATCH のどれかを判定して申告する**——**規約の追加・修正は PATCH、新章・新 Skill は MINOR。**
- ⚠️ **例外条項も見る**——**適用範囲の表だけを見て「不発火」と申告した実例がある**（同じ決定の1行下に例外があった）。
- **タグを打つ対象は「適用範囲に入るファイルを含む最後の commit」。**

## 検出物の扱い

- **直した分は、別の commit に分ける。** ⇒ **検査が機能した証拠を履歴に残すため**（`amend` で潰さない）。
- **push の承認は、commit の承認とは別に取る。** ⚠️ **提案の中で commit と push をまとめて承認させない。**
- 🔴 **公開リポジトリのとき: 公開後の訂正は履歴に残る。** ⇒ **ここで止めるコストのほうが安い。** **深夜の公開 push を避ける**——**遅らせて効くのは操作ミス・誤公開であって、稼働時間の露出ではない。**

## Output Format

```
## 対象（公開 / 非公開）
## 到達状態
- 入口から着手先が決まるか: …
- 3つの壊れ方: 参照 / 時点語 / 件数

## 構造の変更と、それを指す行
## 確度ラベルの再読
## 到達の測り方（不変条件）

## 公開リポジトリのとき（非公開なら「対象外」と1行書く）
- 新規読者の視点（入口 / 内輪の語 / 記号・略語）
- 機微検査（対象・パターン・件数の実測）
- 版チェック（適用範囲に触れたか / MAJOR・MINOR・PATCH / 例外条項）

## 提案（直す / 記録して残す / 版を切る）
## 承認のお願い（push のみ）
- 末尾に `y`（実行）／`n`（差し戻し）を置く
```

## この Skill の受入基準（AC）

1. **対象が公開か非公開かを、検査を始める前に宣言した**
2. **「次のセッションが開始できるか」に答えている**（読んだ範囲の報告で終わっていない）
3. **3つの壊れ方すべてに当てたことが出力から読み取れる**
4. **確度ラベルを1件ずつ読み直した**（「問題なし」の一言で済ませていない）
5. **到達を hash の一致ではなく不変条件で測った**
6. **公開リポジトリのときは、機微検査を「実測」で報告し（パターンと対象範囲を示している）、版チェックの判定理由を書き（不発火なら「なぜ適用範囲外か」）、内輪の語を名指しで検査した**
7. **push の承認を、commit の承認と別に求めた**
8. **検索語つきポインタを、両方の表記で実際に引いて確かめた**（構造を変えた回）
9. **承認を求める文が、半角小文字1文字（`y`／`n`）で打ち返せる形で終わっている**

## 運用規律

- **規律の本体は `01`「外に出る直前に検査を挟む」と `CLAUDE.md`。** この Skill が持つのは手順だけ。
- 🔴 **この1本で公開・非公開の両方を覆う。** ⚠️ **他の Skill を呼ぶ前提を持たない**——**自足させることで、呼び出す本数を増やさない。**
- **commit 直前の検査は `review-before-commit`。**
- **既定手順: 非公開側で先に書き、人間と AI が合意したものだけを公開側に書き込む。** ⇒ **公開リポジトリでこの Skill を回す時点で、合意は済んでいるはずである。**
- **この Skill は push の可否を判定しない。** 判定するのは人間である。