mryo0826 push 直前の検査
push は外に出る操作である。 commit はローカルに留まり amend / reset で巻き戻せるが、push は戻すのに履歴へ revert を積むか force push が要る（別マシンに clone があれば整合も壊れる）。⇒ 検査の重さは、操作の非可逆性に合わせる。
この 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 する。 ⇒ 実体の置き場所を指す行は、構造を変えるたびに必ず腐る。
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. 検出物の扱い
- 直した分は、別の commit に分ける。 ⇒ 検査が機能した証拠を履歴に残すため（
amendで潰さない）。 - push の承認は、commit の承認とは別に取る。 ⚠️ 提案の中で commit と push をまとめて承認させない。
Output Format
## 到達状態
- 入口から着手先が決まるか: …
- 3つの壊れ方: 参照 / 時点語 / 件数
## 構造の変更と、それを指す行
## 確度ラベルの再読
## 到達の測り方（不変条件）
## 提案（直す / 記録して残す / 別 commit に分ける）
この Skill の受入基準（AC）
- 「次のセッションが開始できるか」に答えている（読んだ範囲の報告で終わっていない）
- 3つの壊れ方すべてに当てたことが出力から読み取れる
- 確度ラベルを1件ずつ読み直した（「問題なし」の一言で済ませていない）
- 到達を hash の一致ではなく不変条件で測った
- push の承認を、commit の承認と別に求めた
運用規律
- 規律の本体は
01「外に出る直前に検査を挟む」とCLAUDE.md。 この Skill が持つのは手順だけ。 - 公開リポジトリへの push には使わない——そちらは
review-before-publish（機微検査と版チェックが増える）。 - この Skill は push の可否を判定しない。 判定するのは人間である。