| name | safe-to-publish |
| description | 任意の public repo に push しようとしている差分が「公開して大丈夫か」を意味的にレビューする。 機械的な secret・既知パターン検出 (leak-scan skill / gitleaks) が拾えない穴を埋める層で、 正規表現には引っかからないが公開すべきでない「内部の文脈・知識・固有名・個人情報」を 文章として読んで気づく。public repo へ commit/push する前、あるいは「これ公開して平気?」 「safe to publish か見て」と問われたときに使う。出力は OK か、懸念箇所のリスト (箇所・理由・対処案) で、最終判断はユーザーに委ねる。 |
safe-to-publish — 公開して大丈夫かを意味的にレビューする
任意の public repo へ push する差分に、社内・個人の情報が混入していないかを 意味で
判断する。機械的なパターンマッチは別レイヤー（leak-scan skill / gitleaks）が担うので、
ここは「regex では拾えないが、人間が読めば公開すべきでないと分かるもの」に集中する。
leak-scan との住み分け
公開前チェックは「leak-scan（機械層）→ この skill（意味層）」の順で重ねる。機械層がカバーする確定パターンはここでは指摘しない（詳細は leak-scan skill 参照）。
この skill が拾うもの（意味的リーク）
- 社内システム・サービス・プロジェクトの固有名やアーキテクチャ
メールアドレス等の決まった形を取らないため regex では拾えないが、
公開すると内部構成が見えるもの（内部ツール名、社内エンドポイント、コードネーム）。
- 社内議論・会議・戦略の文脈や引用
「〜という方針で進めることになった」のような地の文。マーカーは付いていないが、
出所が社内のやり取りだと読めば分かるもの。
- 個人を特定しうる情報
同僚・関係者の名前、社内でのやり取りの引用、人事・評価に触れる記述。
- 組み合わせて内部が見えるもの
単体では無害でも、他の公開情報と合わさると組織構成・取引先・進行中の案件が
推測できてしまうもの。
手順
- 範囲を決める
- 引数なし → staged 差分 (
git diff --staged)。staged が空なら working tree (git diff)。
- 範囲指定あり (例
origin/main..HEAD) → その範囲の diff。
- diff を読む。追加・変更行を中心に、上記「意味的リーク」の観点でレビューする。
- 機械層の領域は指摘から除く。secret やドメインメール等を見つけても、それは leak-scan /
gitleaks の領分なので、ここでは重複して挙げない（見落としが怖ければ一言添える程度）。
- 判定して出力する。
出力
- 問題なし: 「公開して問題なし」と簡潔に。確認した観点を一行で添える。
- 懸念あり: 確定的に止めず、判断材料を渡す。各懸念を次の形で:
- 箇所:
file:line または該当文字列
- 理由: なぜ公開すべきでないと考えるか（どの観点に当たるか）
- 対処案: 削除 / 一般化 / private repo へ移す / そのまま公開可と判断する余地、など
最終判断はユーザーが行う。この skill は「気づき」を提供する層であって、push をブロックする
ゲートではない（ブロックは leak-scan の pre-push フックの役割）。
