經驗包
一句話：每個專案都維護自己的經驗帳本；邊界測試提煉出可移植的部分；只有可移植的部分才能在專案間傳遞。
可接受打字或語音輸入：對於「剛剛出了什麼問題」的雜亂、口語化、混合語言的描述，都是帳本條目的有效原始素材——技能會將其結構化，使用者只需確認。
兩個層次
| 層次 | 檔案 | 擁有者 | 內容規則 |
|---|---|---|---|
| 帳本 | 專案根目錄下的 EXPERIENCE.md | 專案本身 | 附有日期、具體、允許專案細節；僅限過程經驗——絕非產品事實，也非決策記錄 |
| 可移植 | 專案的可移植教訓檔案（例如 LESSONS.md）和/或此技能的參考包 | 可傳遞 | 抽象、不含產品名詞、在另一個由陌生人查看的不同專案中仍然成立 |
流程：發生事件 → 帳本條目（當天記錄，趁它還在痛）→ 定期提煉 → 可移植教訓。策略和產品決策永不傳遞：經驗傳承，決策消亡。
協定 A — 記錄（帳本）
先確定根目錄。 帳本存在於專案根目錄——所以在寫入前，請確認有一個專案根目錄。如果當前工作目錄是家目錄、桌面、下載或其他非專案位置，請詢問此經驗屬於哪個專案，並將帳本寫入該處。切勿在家目錄或桌面目錄下建立 EXPERIENCE.md。如果無法確定專案目錄，或目標目錄無法寫入，請勿默默地丟棄該條目：應輸出格式完整的條目為可複製文字，並告知使用者它最終應該放在哪裡。
在專案根目錄下，於第一天（或首次使用時）建立 EXPERIENCE.md。當發生以下任何事件時，附加一個條目：事件耗費了實際的時間/金錢/信任；某個方法明顯有效；一位獨立的審查者發現了作者遺漏的問題；協作模式成功或失敗；使用者糾正了代理的方向。
條目格式：
### YYYY-MM-DD — 標題
**發生什麼事：** 事實，具體。
**我們做了什麼：** 應對措施，具體。
**什麼有效 / 什麼失敗：** 兩者都要，誠實記錄。
**成本：** 時間 / Token / 信任 / 返工。
**可移植？** 是 → <教訓代號> | 尚未 | 否（專案特定）。
規則：記錄過程經驗，而非產品事實；如果工作區有污染衛生規則（禁止使用的名詞），帳本也須遵守；絕不倒填日期或重寫舊條目——應新增條目作為更正。以專案使用的語言撰寫帳本條目（遵循使用者的既有習慣；如果不確定，詢問一次）。
綁定規則（源自此包的採用者專案）：
- 記錄是完成的一部分。 在帳本條目建立之前，事件的修復可能不會被宣告完成——帳本是閘門，而非日記。（一位早期採用者一天內補錄了 8 個條目，因為事件發生時沒有強制寫入；救火行動永遠不會留時間寫日記。）
- 導入是正當的，但倒填日期是不正當的。 在採用此包於有歷史的專案時：每個條目按其事件日期標註日期，並在帳本頂部的備註中宣告導入。一個標註過去日期但沒有宣告導入的條目是偽造。
- 分發衛生。 帳本包含專案內部資訊。在具有公開遠端儲存庫的倉庫中，預設將
EXPERIENCE.md加入 gitignore；僅發布經過邊界測試的可移植層。 - 可發現性。 在專案的主要真相檔案（CLAUDE.md / AGENTS.md / 系統地圖 / 狀態文件）中添加一條指標行，以便零上下文的代理能夠找到帳本；無法發現的帳本無法為下一次對話記錄任何內容。
- 被 gitignore 的帳本需要宣告逃生路線。 將帳本加入 gitignore（上述規則）也會將其從 clone/push 復原中移除。被 gitignore 的帳本必須有宣告的備份或同步管道——一個私有儲存庫或分支、一個同步檔案夾、一個排程複製；由使用者選擇——記錄在帳本標頭備註中的一行文字。沒有這個，更換機器或重新 clone 會悄悄地抹去專案的記憶：切換機器變成無人注意的失憶症，直到下一次事件重複發生。
協定 B — 提煉（邊界測試）
對於每個標記為「可移植？是/尚未」的帳本條目，依序執行以下測試：
- 替代測試——移除所有專有名詞和特定數字。陳述仍然有教育意義嗎？崩潰 → 它是個決策，消亡。
- 機制 vs 選擇——它說的是事物如何運作或失敗（機制 → 繼承），還是誰/什麼/多少被選擇（選擇 → 消亡）？
- 重新推導測試——一個聰明的陌生人能否從新專案的自身脈絡中重新推導出它？如果它只可能來自舊專案的策略，那就是舊策略在說話——消亡。
- 沈沒成本測試——它的唯一價值是不是就是花費了精力？消亡。
- 可驗證性測試——驗證它是否需要一個已死的名詞？將其抽象化，或讓它消亡。
倖存者被改寫為一條抽象的祈使句 + 原因 + 如何應用，並標記出處（「先前專案，提煉 · 日期」）。以英文（或雙語）撰寫可移植層：帳本可以使用專案運作時的任何語言，但可移植教訓會傳遞給陌生人——專案慣用語會讓它們難以理解。不明確的項目預設為消亡——帳本會保留它們，以便在後續提煉中恢復。降級（罕見）：一個策略形狀的成品只有在使用者明確要求下，並帶有重新驗證條件，才能作為明確的假設重新進入另一個專案——絕不能默默進行。
協定 C — 分享 / 應用（另一個專案從此專案學習）
- 在接收專案中：閱讀
references/rebuild-experience-pack.md（此技能的封裝傳奇）和/或來源專案的可移植教訓檔案——絕不能讀取來源專案的帳本、真相檔案或策略。 - 建立接收專案自己的
EXPERIENCE.md（協定 A，包括根目錄判定）。 - 將此包的五個建議作為設定清單執行；採用適用的；將偏差記錄為接收專案的第一個帳本條目。
- 採用的教訓以出處標記進入接收專案；它們是工程約束，而非使用者決策——使用者可以重新分類其中任何一個。
邊界——此技能永不執行的事項
- 絕不將策略、產品事實、人物誌、定價、管道、客戶名稱或帳戶身份在專案之間複製——無論方向如何。
- 絕不將帳本視為決策記錄；決策存在於專案自己的真相/決策檔案中，並遵循其自身的出處規則。
- 絕不編輯其他技能或使用者的全域設定。
- 絕不讀取專案的隔離/封存材料來「豐富」包；提煉輸入僅限於帳本和即時檔案。
與相鄰技能的關係
- conclude-rounds——審查當前對話的輪次。使用者說「复盘」或「let's review」關於此對話的內容屬於該技能；此技能擁有超越對話的專案級事後檢討。
- iteration-close——關閉一個持續方向的迭代（提煉、刪除包袱、標記、播種）。如果兩者都已安裝，則將 experience-pack 的協定 B 作為其一部分執行；iteration-close 擁有關閉儀式。兩個技能都必須遵守的警告：「Git 歷史是存檔」僅適用於被追蹤的檔案。未被追蹤/被 gitignore 的素材（公開儲存庫中的私有 IP）沒有存檔——在清除前，應根據明確的本地規則（例如
_retired/）將其隔離；刪除它們是永久遺失，而非清理。 - diagnose-project-rebuild——當一個方向被替換時，這裡的邊界測試與用來決定什麼能存活的測試相同；重建技能擁有診斷和清除機制，並且只接受此技能的可移植層作為輸入。
- 此技能是產品無關的，必須保持如此：如果專案的名詞曾出現在此檔案或其參考資料中，那就是缺陷——將其移除。
引擎說明
此處不依賴任何特定廠商的執行環境。「新對話」和「零上下文探針」指的是任何在沒有先前上下文情況下啟動的代理實例——一個新的聊天、一個子代理或第二個工具。如果缺少技能運行時，請手動套用協定：上述檔案格式和測試本身就是技能。
參考資料
references/rebuild-experience-pack.md——封裝好的、不含名詞的經驗，來自一個真實的五次重建污染傳奇：六個污染門、源鎖重置方法、三探針驗證堆疊、多 AI 協作協議以及五個預防建議。