mryo0826 公開 push 直前の検査
公開は、外に出るだけでなく、読み手が変わる操作である。 内輪の文脈を持たない人間が、初めてこの木を開く。
この Skill は手順だけを持つ。 一般形は 01_ai-driven-dev-strategy.md「外に出る直前に検査を挟む（非可逆な操作のゲート）」、リポジトリ固有の規約は CLAUDE.md にある。
前提思想
review-before-pushの全項目を含む（到達状態・確度ラベル・不変条件での測定）。⇒ その上に3つ足す: 人間の読み手・機微・版。- 公開物は「配布する新しい実体」である。 ⇒ 実体が変われば版が動く。
- 機微は、消し忘れれば漏れる。 ⇒ クレンジング（消す）ではなく抽出（取る）を既定にする——失敗の方向が安全側に倒れる。
手順
1. review-before-push を回す
到達状態・構造変更の波及・確度ラベルの再読・不変条件での測定。ここを飛ばさない。
2. 初めて読む人間の視点
- 入口（README・読み順）から入って、迷わず目的の章に着けるか。
- 内輪の語が漏れていないか——対話でだけ使う呼称（愛称）／役割名と実体名の混同／その場でだけ通じる ID や記号。
- 読者に説明コストを課す記号・略語が、定義なしで出ていないか。
- 役割名で書くべき箇所が、著者環境の実体名になっていないか（読み手ごとに置き場所が違うものは、役割名でなければ成立しない）。
3. 機微検査
全 git 追跡ファイルが対象（push すれば全て可視になるため）。
- メールアドレス／実名／認証情報・トークン／絶対パス／内部 URL・チケット ID
- 書き手の生活・稼働の記録——個々の記述が許容範囲でも、時系列で累積すると稼働の傾向が像を結ぶ。
- 実プロジェクトの情報（ドメイン・外部サービスのページ ID・体制・納期）。
- ⚠️ 判定基準は「内部か外部か」ではなく「書き手の生活・稼働の記録か、内容についての判断の記録か」。
- 🔴 パターンは誤検出を出す。hit の中身を必ず目で確かめる。 ⚠️ 実例: 認証情報を探す
sk-が、task-nameという語の中に当たる。 ⇒ 「件数が0でない」を検出と読まない。 ⭐ 逆向きも同じ——0件だったことを報告するなら、何のパターンを何に当てたかを書く。
4. 版（タグ）の要否を申告する
- 適用範囲のファイルを触ったかを実測する（ガイド本体・制御plane・Skill・セットアップ手順）。
- 触ったなら MAJOR / MINOR / PATCH のどれかを判定して申告する——規約の追加・修正は PATCH、新章・新 Skill は MINOR。
- ⚠️ 例外条項も見る——適用範囲の表だけを見て「不発火」と申告した実例がある（同じ決定の1行下に例外があった）。
- タグを打つ対象は「適用範囲に入るファイルを含む最後の commit」。
5. 検出物の扱い
- 公開後の訂正は、履歴に残る。 ⇒ ここで止めるコストのほうが安い。
- 直した分は別 commit に分ける（検査が機能した証拠を残す）。
- 深夜の公開 push を避ける——遅らせて効くのは操作ミス・誤公開であって、稼働時間の露出ではない。
Output Format
## review-before-push の結果
## 新規読者の視点（入口 / 内輪の語 / 記号・略語）
## 機微検査（対象・パターン・件数の実測）
## 版チェック（適用範囲に触れたか / MAJOR・MINOR・PATCH / 例外条項）
## 提案（直す / 記録して残す / 版を切る）
この Skill の受入基準（AC）
review-before-pushの項目をすべて回したことが出力から読み取れる- 機微検査を「実測」で報告した（パターンと対象範囲を示している。印象で「無い」と書いていない）
- 版チェックの判定理由を書いた——不発火なら「なぜ適用範囲外か」を書いた
- 内輪の語（愛称・役割名／実体名・その場の ID）を名指しで検査した
- 公開の可否を人間に委ねている
運用規律
- 規律の本体は
01「外に出る直前に検査を挟む」とCLAUDE.md。 この Skill が持つのは手順だけ。 - 既定手順: 非公開側で先に書き、人間と AI が合意したものだけを公開側に書き込む。 ⇒ この Skill を回す時点で、合意は済んでいるはずである。
- この Skill は公開の可否を判定しない。 判定するのは人間である。