disclosure-guard

name	disclosure-guard
description	内部由来の知見（ふりかえりの反映・実プロジェクトの検証記録など）を公開リポジトリに出す前に、組織固有の固有名詞（会社名・内部リポ名・顧客名・人物名・プロジェクト名・ID・パス等）の混入を独立点検して防ぐ。公開 git 履歴は遡れて消せないため、コミット / push の前に必ず通す。機密・認証情報の検査は扱わない。

公開前の固有名詞混入ガード

なぜこのスキルがあるか

このリポジトリの改修は、実際のプロジェクトを分析・検証した知見を、ふりかえりやドキュメント・カードとして記録する作業を含む。その「内部の知見 → 公開リポジトリへの記録」の段で、会社名・内部リポ名・顧客名などの組織固有の固有名詞が、意図せず公開 git 履歴に混入するリスクがある。

公開リポジトリの git 履歴は遡れて消せない。一度コミットに入った固有名詞は実質永久に残る＝インシデント。main session の注意力だけに頼らず、外に出す前に独立点検を必ず通す ための規律をここに置く。

いつ通すか

内部由来の知見を含む変更を、公開リポジトリにコミット / push する前 に通す。具体的には:

• ふりかえりの結果を記録するとき
• 実プロジェクトの検証・観察から得た知見を、カード・ドキュメント・skill に反映するとき
• 上記に類する、外部の利用実態に触れた内容を公開リポに出すとき

純粋に harness 内部の設計変更だけ（実プロジェクトに一切触れていない）なら不要。迷ったら通す（通すコストは小さく、漏れたコストは取り返せない）。

どう通すか

コミット / push の前に、disclosure-auditor subagent を呼ぶ。

• 対象: これから公開リポに出す差分（staged diff）、または対象ファイルを指定する
• subagent が会話文脈なしの独立視点で読み、組織固有の固有名詞を flag する
• FLAGGED が出たら、コミット / push しない。該当箇所を一般化・除去してから、もう一度通す
• CLEAN を得てから 外に出す

なぜ subagent（独立点検）か

main session は会話の文脈を持つので「これは匿名化した」「文脈的に大丈夫」と自分の判断を甘くしがち。また、自分が思いついた語を grep で探すだけでは、リストに無い固有名詞を取りこぼす。会話文脈を持たない subagent が、書かれたものだけを読んで判断する ことで、その甘さと取りこぼしを破る。

何を防ぎ、何を防がないか

• 防ぐ: 組織固有の固有名詞の、公開リポへの混入（何を固有名詞とみなすかの詳細は disclosure-auditor が持つ）
• 防がない: 機密・認証情報（パスワード・トークン・秘密鍵 等）の検査。本機構では扱わない（必要なら別途用意する）