mryo0826 公開リポジトリの commit 直前の検査
公開リポジトリの履歴は、push した時点で永久に公開される。 ⇒ diff だけでなく、メッセージ・日時・author・staging の中身が、そのまま読まれる。
🔴 この Skill が要る理由は「漏れるから」ではなく「直すコストが跳ね上がるから」である。 push 前に見つけても直せるが、履歴になった後は amend か rebase になる——小さく commit する運用と組み合わさると、跨る確率が高い。
この Skill は手順だけを持つ。 一般形は 01_ai-driven-dev-strategy.md「外に出る直前に検査を挟む（非可逆な操作のゲート）」、リポジトリ固有の規約は CLAUDE.md にある。
前提思想
- commit の瞬間にしか安く直せないものがある——メッセージ／staging の中身／author。
- commit date は、commit した瞬間に確定する。 ⇒ push を遅らせても稼働時間の露出は減らない（遅らせて効くのは操作ミスと誤公開だけ）。ここで止められるのは「何を・どう書くか」であって、日時ではない。
review-before-commitの全項目を含む。 ⇒ その上に3つ足す: メッセージ・staging・履歴としての露出。
手順
1. review-before-commit を回す
対話にのみ在るものの洗い出し／検査対象の宣言／3軸（参照・時点語・件数）。ここを飛ばさない。
2. コミットメッセージを検査する
- 何をしたかを1行で書く。理由を書かない——理由は判断の記録側、課題は課題一覧側に置く。 🔴 git 履歴は正本ではなく複製であり、意味を載せると二重管理になって必ず片方が腐る。
- ⚠️ 発火の合図: メッセージに理由を書きたくなった瞬間。それが判断の記録へ起票する合図である。 ⇒ 「後で書く」と言わずに、その場で起票する。
- メッセージ自体の機微を見る——実名・メールアドレス・絶対パス・内部 URL・チケット ID・依頼者や案件の名前。
-mを複数指定して渡す（件名と付記を別の-mにする）。⚠️ 複数行の文字列を1つの引数として組み立てない——引用符法を選ぶ場面が生じ、literal が混入する失敗モードに到達できてしまう。
3. staging の中身を1件ずつ提示する
- 🔴
git add -Aを使わない——未追跡ファイルを無検査で取り込むため。 - staging に入るファイルを列挙し、意図しないものが無いかを人間に見せる——下書き・作業メモ・一時ファイル・別の作業の残骸。
- ⚠️
.gitignoreされているものは diff に出ない。 ⇒ 「差分がきれい」は「混入が無い」を意味しない——追跡下に入る瞬間を見る。
4. 履歴として公開されるものを確認する
- author（名前・メールアドレス）が意図した値か。
- この commit が、稼働の傾向を露出させないか——個々の記述が許容範囲でも、時系列で累積すると像を結ぶ。
- 判定基準は「内部か外部か」ではなく「書き手の生活・稼働の記録か、内容についての判断の記録か」。
5. 出力する
staging 内容とメッセージ案を提示して、人間の承認を得る。 ⚠️ commit と push の承認は分ける——提案の中で2つをまとめて承認させない。
Output Format
## review-before-commit の結果
## staging（1件ずつ）
## コミットメッセージ案（件名 / 付記）
- 理由を書いていないか / 機微は無いか
## 履歴としての露出（author / 稼働の傾向）
## 承認のお願い（commit のみ。push は別に伺う）
この Skill の受入基準（AC）
review-before-commitの項目をすべて回したことが出力から読み取れる- staging を1件ずつ列挙した（
git add -Aを使っていない） - メッセージに理由が入っていないことを確認した——入れたくなったなら、判断の記録へ起票してから commit した
- メッセージの機微を名指しで検査した
- commit の承認だけを求めた（push を同じ文で承認させていない）
運用規律
- 規律の本体は
01「外に出る直前に検査を挟む」とCLAUDE.md。 この Skill が持つのは手順だけ。 - 公開リポジトリへの push は
review-before-publish（機微検査と版チェックが増える）。 - この Skill は commit の可否を判定しない。 判定するのは人間である。