xp-harness の公開済みリリースを要約して、チーム周知用の短いテキスト (利用者向けの変化 + 更新手順) を作る。「リリースをアナウンスしたい」「この期間のリリースをまとめて周知したい」「土日の分まとめて」と言われたときに発火。投稿はせずドラフト生成に留める。
sei-newbear/xp-harness92026年9月17日 更新
無料GitHub で公開
disclosure-guard
内部由来の知見（ふりかえりの反映・実プロジェクトの検証記録など）を公開リポジトリに出す前に、組織固有の固有名詞（会社名・内部リポ名・顧客名・人物名・プロジェクト名・ID・パス等）の混入を独立点検して防ぐ。公開 git 履歴は遡れて消せないため、コミット / push の前に必ず通す。機密・認証情報の検査は扱わない。
含まれるファイル（1）
- SKILL.md3.1 KB
SKILL.md（原文）
インストールする前に、エージェントに与えられる指示の中身を確認できます。
公開前の固有名詞混入ガード
なぜこのスキルがあるか
このリポジトリの改修は、実際のプロジェクトを分析・検証した知見を、ふりかえりやドキュメント・カードとして記録する作業を含む。その「内部の知見 → 公開リポジトリへの記録」の段で、会社名・内部リポ名・顧客名などの組織固有の固有名詞が、意図せず公開 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が持つ） - 防がない: 機密・認証情報（パスワード・トークン・秘密鍵 等）の検査。本機構では扱わない（必要なら別途用意する）
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
要件が固まった機能・変更について、アーキテクチャ・ER・シーケンス・論理設計までを対話で固める「基本設計フェーズ」のスキル。docs/working/<title>/要件定義.md が既にある状態で「設計を進めて」「basic-design」と言われたら必ず発火させる。要件定義が終わって設計フェーズに入りたい依頼、データモデルや API 設計や画面遷移の議論、コンポーネント分割や責務分離の相談、「どう作るか」の構造的な設計が必要な場面で使う。
sei-newbear/xp-harness92026年9月17日 更新
新規・変更・削除・改善などの要望やレビュー指摘を受けたら、設計や実装に入る前にまず必ず発火させる「要件定義フェーズ」のスキル。依頼者のインテントを読み取り、Why / Done / スコープ / 影響範囲を引き出す。見える挙動が変わる依頼全般が対象で、やることが具体的でも md にまとめられていても発火させ、複数の要望が混ざる依頼ほど積極的に発火させる。発火しないのは、再現条件と期待動作が完全に明確なバグ修正、依存更新・タイポ修正などの定型作業、要件定義と基本設計の文書が両方揃った実装フェーズの続き（メモや TODO があるだけでは除外しない）だけ。
sei-newbear/xp-harness92026年9月17日 更新
依頼者と議論・対話を進める場面で必ず発火させる skill。共創を目指して、認識を小さく揃えながら、同じ抽象度・レイヤーで話すための対話の進め方を扱う。要件・設計フェーズの対話、実装中の設計判断の議論、レビュー結果の共有、複数の論点・選択肢を依頼者に渡す場面、依頼者からの指摘・反論に応答する場面、「確認したい」「議論したい」「相談したい」と問いかけたいとき、いずれも発火対象。「会話」ではなく「対話」を成立させたい全場面で効く。質問がスルーされる・訂正が続く・話題を変えられる・「そうじゃなくて」と返されるなど、噛み合っていない兆候を観測したときは軌道修正のために再度発火させる。
sei-newbear/xp-harness92026年9月17日 更新
E2E テストの spec を書く・編集する・レビューする際に必ず発火させる。新しいシナリオの追加、既存 E2E テストの修正・デバッグ、E2E テストの書き方の相談、slice-tdd skill から E2E spec が必要と判断された場面で使う。触る範囲に対応するプロジェクトの E2E の流儀 (spec の書き方・構造・命名) を探して従わせる入口。E2E を実行する手順は扱わない (別スキルの責務)。
sei-newbear/xp-harness92026年9月17日 更新
E2E テストを実行する手順に沿って E2E を動かす際に発火させる。実行環境のセットアップ、実行コマンド、CI 統合、実行が失敗したときの対処など、E2E を「動かす」場面で使う。触る範囲に対応するプロジェクトの実行手順を探して従わせる入口。E2E spec を書く・レビューするのとは別の責務 (spec の書き方は扱わない)。
sei-newbear/xp-harness92026年9月17日 更新