m1nga/experience-pack

Experience Pack

一文で言うと：すべてのプロジェクトは独自の経験台帳を持ち、境界テストが移植可能な部分を抽出し、移植可能な部分だけがプロジェクト間を移動します。

タイプ入力または口述入力に対応：乱雑で、口語的で、多言語混在の「何がうまくいかなかったか」という記述は、台帳エントリーの有効な原材料です。スキルがそれらを構造化し、ユーザーは確認するだけです。

二つのレイヤー

レイヤー	ファイル	所有者	コンテンツルール
台帳	プロジェクトルートの EXPERIENCE.md	プロジェクト	日付付き、具体的、プロジェクト固有の情報を許容。プロセス経験のみ — 製品の真実は決して含まず、決定台帳ではない
ポータブル	プロジェクトのポータブル教訓ファイル（例：LESSONS.md）および/またはこのスキルのリファレンスパック	移動する	抽象的、製品名を含まない、異なるプロジェクトで見知らぬ人が読んでも真実であること

パイプライン：何かが起こる → 台帳エントリー（同じ日、痛みがあるうちに）→ 定期的な抽出処理 → ポータブル教訓。戦略と製品の決定は決して移動しない：経験は継承され、決定は消滅する。

プロトコルA — 記録（台帳）

最初にルートの確認。 台帳はプロジェクトルートに存在するため、書き込み前にプロジェクトルートが存在することを確認してください。現在の作業ディレクトリがホームディレクトリ、デスクトップ、ダウンロード、その他のプロジェクト以外の場所である場合は、この経験がどのプロジェクトに属するかを尋ね、そこに台帳を書き込んでください。ホームディレクトリやデスクトップディレクトリに EXPERIENCE.md を作成しないでください。プロジェクトディレクトリを確定できない場合、またはターゲットが書き込み可能でない場合は、エントリーを黙って破棄せず、完全にフォーマットされたエントリーをコピー可能なテキストとして出力し、最終的にどこに置くべきかをユーザーに伝えてください。

初日（または初回使用時）にプロジェクトルートに EXPERIENCE.md を作成します。以下のいずれかが発生した場合にエントリーを追加します：インシデントにより実際の時間/費用/信頼を消費した；メソッドが明らかに機能した；独立したレビューアが作成者が見逃した何かを発見した；コラボレーションパターンが成功または失敗した；ユーザーがエージェントの方向性を修正した。

エントリー形式：

### YYYY-MM-DD — タイトル
**何が起こったか：** 事実、具体的に。
**私たちがしたこと：** 対応、具体的に。
**うまくいったこと／うまくいかなかったこと：** 両方を正直に。
**コスト：** 時間 / トークン / 信頼 / 手戻り。
**ポータブル？** はい → <教訓スラッグ> | まだ | いいえ（プロジェクト固有）。

ルール：製品の事実ではなくプロセスの経験を記録すること。ワークスペースに汚染衛生ルール（禁止名詞）がある場合、台帳はそれに従うこと。過去のエントリーを遡って日付変更したり書き換えたりしないでください。修正は新しいエントリーとして追加してください。台帳エントリーはプロジェクトが使用している言語で書いてください（ユーザーの既存の習慣に従い、不明な場合は一度尋ねてください）。

バインディングルール（パックの採用プロジェクトから抽出）：

• 記録は完了の一部である。 インシデントの修正は、その台帳エントリーが存在するまで完了と宣言してはなりません。台帳はゲートであり、日記ではありません。（初期の採用プロジェクトでは、インシデント発生時に記録を強制するものがなかったため、1日で8つのエントリーを遡って作成しました。火災対応に日記を書く時間は決して残りません。）
• ブートストラップインポートは正当だが、黙っての過去日付は認められない。 履歴のあるプロジェクトにパックを採用する場合：各エントリーをインシデント発生日で日付付けし、台帳の上部に日付付きの注注釈でインポートを宣言してください。宣言されたインポートなしに過去の日付のエントリーを作成することは捏造です。
• 配布衛生。 台帳にはプロジェクト内部情報が含まれています。パブリックリモートを持つリポジトリでは、デフォルトで EXPERIENCE.md をgitignoreし、境界テストを通過したポータブルレイヤーのみを公開してください。
• 発見可能性。 プロジェクトの主要な真実ファイル（CLAUDE.md / AGENTS.md / システムマップ / 状態ドキュメント）に1行のポインタを追加し、ゼロコンテキストのエージェントが台帳を見つけられるようにしてください。発見できない台帳は次のセッションのために何も記録しません。
• gitignoreされた台帳には、宣言された脱出経路が必要です。 台帳をgitignoreすると（上記ルール）、クローン/プッシュからの復元も除外されます。gitignoreされた台帳には、宣言されたバックアップまたは同期チャネル（プライベートリポジトリまたはブランチ、同期フォルダ、スケジュールされたコピー）が必須であり、ユーザーが選択し、台帳のヘッダーノートに1行で記録します。これがないと、マシンの変更や再クローンはプロジェクトのメモリを黙って消去します。マシンの切り替えは、次のインシデントが繰り返されるまで誰も気づかない記憶喪失になります。

プロトコルB — 抽出（境界テスト）

「ポータブル？ はい/まだ」とマークされた各台帳エントリーについて、順にテストを実行します：

1. 置換テスト — すべての固有名詞と特定の数値を削除します。そのステートメントはまだ何かを教えていますか？ 崩壊する → それは決定であり、消滅します。
2. メカニズムと選択 — 物事がどのように機能するか、または失敗するかを述べていますか（メカニズム → 継承）、または誰が/何が/どれだけが選択されたかを述べていますか（選択 → 消滅）？
3. 再導出テスト — 賢い見知らぬ人が新しいプロジェクトの独自のコンテキストからそれを再導出できますか？ 古いプロジェクトの戦略からしか得られないのであれば、それは古い戦略が話しているのです — 消滅します。
4. サンクコストテスト — その唯一の価値は、それに努力が費やされたことですか？ 消滅します。
5. 検証可能性テスト — それをチェックするために死んだ名詞が必要ですか？ 抽象化するか、消滅させてください。

生き残ったものは、1つの抽象的な命令行 + 理由 + 適用方法として書き直され、出典（「先行プロジェクト、抽出済み · 日付」）でタグ付けされます。ポータブルレイヤーは英語で（またはバイリンガルで）書いてください：台帳はプロジェクトが使用する任意の言語を使用できますが、ポータブルな教訓は見知らぬ人に届きます。プロジェクト固有の慣用句はそれらを孤立させます。

曖昧な項目はデフォルトで消滅します — 台帳はそれらを後で再評価できるように保持します。 ダウングレード（稀）：戦略の形をした成果物は、明示的な仮説として再検証条件とともにのみ、かつユーザーの呼びかけによってのみ、別のプロジェクトに再入力されます。決して黙って行われません。

プロトコルC — 共有 / 適用（別のプロジェクトがこれを学ぶ）

1. 受信プロジェクトで：references/rebuild-experience-pack.md（このスキルのパッケージ化されたサガ）および/またはソースプロジェクトのポータブル教訓ファイルを読みます — ソースプロジェクトの台帳、真実ファイル、戦略は決して読まないでください。
2. 受信プロジェクト自身の EXPERIENCE.md（プロトコルA、ルート確認を含む）をブートストラップします。
3. パックの5つのアドバイスをセットアップチェックリストとして実行し、適用可能なものを採用し、逸脱を受信プロジェクトの最初の台帳エントリーとして記録します。
4. 採用された教訓は、出典がタグ付けされて受信プロジェクトに入力されます。それらはエンジニアリング上の制約であり、ユーザーの決定ではありません — ユーザーはそれらのいずれも再分類できます。

境界 — このスキルが決して行わないこと

• プロジェクト間で戦略、製品事実、ペルソナ、価格、チャネル、クライアント名、アカウントIDをコピーしません（どちらの方向でも）。
• 台帳を決定台帳として扱いません。決定は、プロジェクト自身の真実/決定ファイルに、独自の出典ルールとともに存在します。
• 他のスキルやユーザーのグローバル設定を編集しません。
• プロジェクトの隔離/アーカイブされたマテリアルを「パックを強化する」ために読みません。抽出入力は台帳とライブファイルのみです。

隣接スキルとの関係

• conclude-rounds — 現在の会話のラウンドをレビューします。この会話についてユーザーが「復習」または「振り返り」と言った場合は、そこに属します。このスキルは、会話を超えて存続するプロジェクトレベルの事後分析を担当します。
• iteration-close — 継続中の方向性のイテレーションを閉じます（抽出、バッジの削除、タグ付け、シード）。両方がインストールされている場合は、experience-packのプロトコルBをその一部として実行します。iteration-closeがクロージャの儀式を所有します。両方のスキルが尊重しなければならない注意点： 「git履歴がアーカイブである」は、追跡されたファイルにのみ当てはまります。追跡されていない/gitignoreされたマテリアル（パブリックリポジトリ内のプライベートIP）にはアーカイブがありません。明示的なローカルルール（例：_retired/）の下で隔離してからパージしてください。それを削除することは恒久的な損失であり、クリーンアップではありません。
• diagnose-project-rebuild — 方向性が置き換えられた場合、ここでの境界テストは何が生き残るかを決定するために使用されるのと同じテストです。リビルドスキルは診断とパージのメカニズムを所有し、このスキルのポータブルレイヤーのみを入力として受け取ります。
• このスキルは製品に依存せず、その状態を維持しなければなりません。プロジェクトの名詞がこのファイルまたはそのリファレンスに表示された場合、それは欠陥です — 削除してください。

エンジンノート

ここにあるものは特定のベンダーのランタイムに依存しません。「新しいセッション」と「ゼロコンテキストプローブ」は、以前のコンテキストなしで開始された任意のエージェントインスタンス（新しいチャット、サブエージェント、または2番目のツール）を意味します。スキルランタイムがない場合は、上記のファイル形式とテストがスキルであるため、プロトコルを手動で適用してください。

リファレンス

references/rebuild-experience-pack.md — 実際の5回のリビルド汚染サガからのパッケージ化された、名詞を含まない経験：6つの汚染ドア、ソースロックリセットメソッド、3プローブ検証スタック、マルチAIコラボレーションプロトコル、および5つの予防アドバイス。