archive

archive skill 概覽

archive 擅長做什麼

archive skill 適合想把一次性的工作階段知識，轉成可重複利用專案記憶的團隊與個人開發者。它不會讓修復方法繼續埋在聊天紀錄裡，而是把除錯結論、部署備註與流程中的學習，依結構化 markdown 存進 .archive/YYYY-MM-DD/，再把精簡索引維護在 .archive/MEMORY.md。

誰適合安裝 archive

這個 archive skill 特別適合那些會反覆遇到相同基礎設施、CI、發布或除錯問題的人，並希望下次能更快恢復處理。尤其當你的工作會跨多個 session、多個 agent，或多位協作者都需要共享「上次到底發生了什麼？」這類紀錄時，它會很有幫助。

真正要解決的工作需求

使用者缺的不是另一套記筆記習慣，而是一種可靠的方法：在有價值的任務剛完成後，立刻保存重要技術脈絡，並在下一次遇到類似任務前，把這些內容重新帶回來。archive 的設計核心就是這個工作流程，而不是泛用文件撰寫。

為什麼 archive 跟一般 prompt 不一樣

一般 prompt 也能叫 AI「幫我整理我們剛做了什麼」。但 archive skill 額外提供了可重複執行的儲存模式、必須更新的記憶索引，以及在 session 開始時若存在 .archive/MEMORY.md 就自動載入的 hook。這也讓 archive for Knowledge Bases 變得實用：archive 會成為後續工作的上下文之一，而不只是某個最後被遺忘的 markdown 檔案。

安裝前要先知道的取捨

archive 刻意保持簡單。它不提供資料庫、向量搜尋，也沒有自動分類流程。它的價值來自有紀律的檔案結構、可搜尋的 tags，以及記憶索引。如果你的團隊不會持續維護 .archive/MEMORY.md，那這個 archive skill 的優勢就會失去大半。

如何使用 archive skill

archive 安裝方式與最先該讀的 repository 檔案

實際可行的 archive install 路徑如下：

1. 在你的 skills system 中，從 ReScienceLab/opc-skills repository 加入這個 skill。
2. 先讀 skills/archive/SKILL.md，掌握整體 workflow。
3. 再讀 skills/archive/references/TEMPLATE.md，確認 archive 的必要格式。
4. 如果你在意啟動時的上下文載入，再看 skills/archive/hooks/hooks.json 與 skills/archive/hooks/load-memory.py。
5. 檢查 skills/archive/.factory-plugin/plugin.json，確認它原本預期的行為。

如果你只能快速看一個輔助檔案，那就看 references/TEMPLATE.md；它最能直接告訴你什麼叫做「好的 archive 輸出」。

archive skill 需要哪些輸入

archive skill 最適合在你提供以下資訊時使用：

• 已完成的任務或事件
• 主要結果
• 採取過的關鍵步驟
• 重要指令、設定變更或程式碼決策
• 失敗點與最後的修復方式
• 類別與可能的 tags
• 任何相關的舊 archive 紀錄

少了這些輸入，最後存下來的 archive 往往會太空泛，之後幫助不大。

什麼時候該觸發 archive

建議在以下情況後使用 archive：

• 成功完成一次部署
• 處理過一場棘手的除錯 session
• 做完遷移或基礎設施變更
• 完成重大功能
• 使用者明確要求「archive this」

不要每個小修改都用。這個 skill 是拿來保存耐用的經驗，不是拿來堆積吵雜活動日誌。

archive 在實務上的使用流程

建議 workflow 如下：

1. 先查看 .archive/MEMORY.md，找是否有相關舊紀錄。
2. 建立或重用 .archive/YYYY-MM-DD/。
3. 依照 template 結構與 YAML frontmatter 撰寫 markdown archive。
4. 在 .archive/MEMORY.md 新增一行索引條目。
5. 用 related 欄位串連相關紀錄。

更新這個索引不是可有可無的行政動作，而是未來能快速查找的關鍵。

更有效的 archive skill 提示方式

弱的 prompt：

• 「Archive this session.」

更好的 prompt：

• 「Use the archive skill to document today’s ECS deploy issue. Include the IAM permission error, the CloudWatch clue, the exact fix, final deploy status, tags for ecs, iam, deploy, category infrastructure, and add a one-line entry to .archive/MEMORY.md. If a related archive exists, link it.”

後者提供了足夠結構，模型才能產出真正可重用的內容。

如何把模糊目標變成完整的 archive 請求

如果你的原始目標只是「把這次學到的東西存下來」，最好展開成：

• 發生了什麼事
• 為什麼重要
• 哪裡失敗了
• 最後怎麼修好
• 下次第一步應該先檢查什麼
• 這應該歸在哪個 category
• 之後別人應該透過哪些 tags 找到它

這個 skill 更重視為了「之後找得到」而寫，不是為了敘事完整而寫。

archive template 中最重要的欄位

依照 references/TEMPLATE.md，最重要的欄位是：

• tags：給 grep 類型檢索使用
• category：用來整理索引
• related：把不同時間的事件串起來

在內文部分，通常最有價值的區塊是：

• Summary
• Issues Encountered & Solutions
• Key Changes

如果你略過具體修復細節，archive 的實用性會大幅下降。

session-start memory hook 如何改變 archive 的使用價值

這個 hook 會在 session 啟動時、檔案存在的情況下，把 .archive/MEMORY.md 載入上下文。這代表 archive skill 不只是拿來寫紀錄；它也會自動強化之後的回憶與查找能力。從導入角度來看，這是比起隨手寫一個 notes 檔，更值得安裝這個 skill 的重要理由之一。

archive for Knowledge Bases 與團隊記憶

若從 archive for Knowledge Bases 的角度來看，可以把 .archive/MEMORY.md 視為目錄，而每個帶日期的 markdown 檔則是某次事件或任務的紀錄。這種做法特別適合：

• 反覆出現的營運問題
• 有陷阱要注意的發布檢查清單
• 特定環境才會出現的修復方式
• 具有後續影響的設計決策

但它不太適合拿來寫廣泛的產品文件或面向使用者的操作手冊。

archive 的實際搜尋與查找流程

這個 skill 明確支援輕量搜尋流程：

• 先看 .archive/MEMORY.md
• 使用 grep -ri "keyword" .archive/

對許多工程團隊來說這樣就夠了，因為存下來的內容通常範圍明確、技術導向，而且結構清楚。請使用大家之後真的會拿來搜尋的 tags：服務名稱、錯誤字串、平台名稱、元件名稱。

archive skill 常見問題

如果我本來就有寫筆記，archive 還值得安裝嗎？

值得，如果你現在的筆記很難找，或根本不會重新進入 agent 的上下文。archive skill 的價值在於它把位置、結構、索引與 session-start 的記憶載入標準化。

這個 archive skill 對新手友善嗎？

大致上是友善的。它的 workflow 就是簡單的 markdown 加上一個索引檔。新手最常見的風險，是把摘要寫得太抽象。最容易上手的方式，是直接複製 template，然後填入具體的修復方法、指令與經驗教訓。

什麼情況不該用 archive？

不要把 archive 用在：

• 瑣碎修改
• 暫時性的腦力激盪
• 長篇正式文件
• 原本就應該放進永久 repo 文件的知識，例如 README.md 或 runbooks

如果某項資訊應該長期、持續地指引所有協作者，那它可能應該放在標準文件裡，而不只是 .archive/。

archive 跟一般專案文件有什麼不同？

一般文件描述的是系統原本「應該如何運作」。archive usage 記錄的則是某次任務或事件中「實際發生了什麼」：走過哪些錯路、精確的修復方式、以及那些通常最容易流失的上下文。它是一層歷史性的營運記憶，不是 canonical docs 的替代品。

archive 需要特殊工具嗎？

不太需要。核心格式就是 markdown 檔案加上 .archive/MEMORY.md。repo 裡另外有一個 hook，能在 session 開始時載入記憶；但即使不用它，archive skill 仍然可以作為一種有紀律的儲存模式運作。

這份 archive 指南的邊界在哪裡？

這份 archive 指南反映的是 repository 目前實際支援的能力：以檔案為基礎的 archives、索引化記憶、簡單 categories、related links，以及用 hook 做 recall。它不代表有自動摘要流程、語意搜尋，或外部 knowledge base 同步能力。

如何改善 archive skill 的使用效果

archive 條目要為了「之後查得到」而寫，不是為了說故事

最好的 archive 輸出，是之後回頭看時可以快速掃描的。把問題、修復方式與關鍵指令放在未來讀者最容易找到的位置。寫得像精緻敘事，不如寫成直接、可搜尋的紀錄來得有價值。

使用大家真的會搜尋的 tags

好的 tags：

• 服務或工具名稱
• 精確的子系統名稱
• 部署平台名稱
• 錯誤關鍵字
• 受影響的環境名稱

不好的 tags：

• 像 issue、work、update 這種模糊字眼

這是提升 archive 使用品質最划算的做法之一。

讓 MEMORY.md 真正有用，而不是流於形式

弱的索引條目會寫：

• 「Fixed deployment issue」

強的索引條目會寫：

• “ECS deploy failed due to missing IAM permission for secret access; resolved by updating task role policy”

索引應該幫助讀者判斷下一步該打開哪一份 archive。

當失敗嘗試會影響未來決策時，也要記下來

如果團隊在找到正確解法前，先試了兩個錯誤修法，而且這些失敗經驗能避免之後重複浪費時間，就應該寫進去。這正是 archive skill 常常比標準文件更有價值的地方：它保留了那些真正重要的死路。

想得到更好的 archive 輸出，就先提供更好的輸入

在請 skill 做 archive 之前，先整理好：

• 精確的錯誤訊息
• 相關指令
• 變更過的檔案或設定
• 最終驗證過的狀態
• 為什麼最後的修復有效

這些細節會直接影響之後能不能重用，也會影響搜尋效果。

archive skill 使用時常見的失敗模式

常見問題包括：

• 沒有更新 .archive/MEMORY.md
• tags 太泛
• 沒有清楚 category
• 只有摘要，沒有操作層細節
• archive 條目與過往事件沒有關聯

多數品質不佳的 archive 結果，問題不在 template，而在輸入資訊不完整。

完成第一版 archive 草稿後再做一次修正

第一版寫完後，請檢查：

• 別人能不能用合理的搜尋詞找到這份紀錄？
• 摘要有沒有寫出結果與原因？
• 關鍵指令或設定變更有沒有包含進去？
• 未來的 agent 看了之後，知不知道第一步該先試什麼？
• 需不需要連到某個較早的相關條目？

通常只要再做一次簡短修訂，archive 品質就會提升很多。

把 archive 跟永久文件一起用，而不是互相取代

如果這次 session 暴露出某條應該永久保存的規則，也要同步更新 canonical doc。archive skill 應該保存的是事件層級知識，不該變成唯一存放關鍵團隊指引的地方。

用清楚的團隊觸發條件提升 archive 採用效果

當團隊定義明確觸發條件時，archive 通常更容易發揮價值，例如：

• 每一次有意外狀況的 production deploy
• 每一個修法不直觀的 incident
• 每一次 migration
• 每一個使用者要求「下次記得保留這個」的情況

這樣能維持 archive 的價值，同時避免把它塞滿雜訊。