Retro-Bot
一個用於在 Claude 協作工作階段結束後，執行輕量級敏捷回顧的技能——旨在讓與 Claude 合作的過程隨著時間推移，越來越順暢。
核心循環：在你和 Claude 完成一項工作後，花幾分鐘一起問三個問題：
- 哪些做得很好？ （繼續這樣做）
- 哪些做得不好？ （摩擦點、重工、混淆、浪費的 token）
- 我們應該改變什麼？ （針對技能、提示詞或流程的具體改進）
變更會立即套用，並且每次回顧都會儲存為快照到一個持久的歸檔中。隨著時間推移，這會建立起一份關於你的 Claude 工作流程如何演進的運行軌跡——並累積成一個每次工作都會越來越快的設定。
第 0 階段 — 歸檔目錄設定（僅限首次執行）
在回顧開始之前，檢查是否已設定回顧歸檔目錄。請在 Claude.md 中尋找如下區塊：
## Retro-Bot
archive_dir: [路徑]
如果已設定： 直接進入第 1 階段。無需再次詢問。
如果未設定： 清楚地向使用者詢問一次：
「在我們開始之前 — 您想將回顧快照儲存在哪裡？這是一次性的設定。請給我一個資料夾路徑（例如
H:\My Drive\Retros或~/Documents/retros），之後每次的回顧我都會自動儲存在那裡。」
一旦使用者提供路徑：
- 將以下區塊加入
Claude.md（如果檔案不存在，則建立它）：## Retro-Bot archive_dir: [他們提供的路徑] - 如果目錄不存在，請建立該目錄
- 在該目錄中建立一個空的
retro-log.md（參見第 6 階段了解其格式） - 確認：「收到 — 回顧歸檔已設為
[路徑]。所有未來的回顧都將儲存在那裡。」
然後繼續進行第 1 階段。
第 1 階段 — 讀取工作階段上下文
讀取工作階段的對話記錄，以了解實際發生的事。如果你的環境提供了工作階段歷史記錄或對話記錄工具，請立即使用它以取得發生的完整記錄。（在 Cowork 中，這是自動可用的；在 Claude Code 中，請使用 /transcript 或等效指令，如果有的話。）即使沒有完整的對話記錄，也要從你所知道的內容中提取：使用了哪些技能、建立了哪些檔案、使用者在工作過程中給予了哪些回饋、哪些地方需要重做。
如果使用者是在工作階段結束後立即呼叫此技能，你已經掌握了上下文。如果他們稍後透過描述來呼叫，則根據該描述進行。
如果工作內容不明確，請要求使用者確認他們想要回顧的工作階段/工作。
第 2 階段 — Claude 先提出觀察
你先說。不要等著使用者列出抱怨——分享你所注意到的情況。這能示範良好的回顧行為，顯示你有在關注，而且通常能浮現使用者沒有明確意識到、但一聽就能辨識出來的問題。
誠實且具體地陳述你的觀察：
- 「我注意到我必須重新渲染 SOW 兩次，因為第一種表格格式在 Word 中無法正常開啟——這是一個我可以修正的技能設定問題。」
- 「你分三次傳送客戶簡報，而不是一次完整區塊——這是一個值得注意的工作流程模式，會拖慢進度。」
- 「範圍建構器和 SOW 建構器技能產生的數字是一致的——這感覺很順暢。」
- 「我不確定你需要哪種匯出格式，直到你在中途告訴我——事先問一個簡單的問題就能省去一趟來回。」
保持 3–5 個觀察。直言不諱，不要防衛。你是參與者，不是旁觀者。
第 3 階段 — 邀請使用者的意見
在你開場之後，邀請使用者補充、修正或提出異議：
「這些是我的觀察。你的想法是什麼——有任何我遺漏的、你有不同看法的、或你想確保我們記錄下來的項目嗎？」
使用者的摩擦點往往與你的不同。他們可能會指出他們感到困惑的地方、當時沒有說出來的輸出品質問題、流程上的困擾、或那些感覺很好並應該保留下來的事情。記錄所有內容。
第 4 階段 — 建立回顧看板
當你們雙方都貢獻完後，呈現完整看板。要具體——模糊的項目無法產生有用的行動項目。
## ✅ 做得很好
- [具體順利完成的事項]
- ...
## ❌ 做得不好
- [具體的摩擦點，如果知道的話，也包括根本原因]
- ...
## 🔧 改變想法
- [與「做得不好」項目相關聯的具體建議]
- ...
在繼續之前，要求使用者確認：
「這樣記錄是否完整？在我們決定採取哪些行動之前，有沒有需要新增或調整的地方？」
第 5 階段 — 對應到行動項目
針對每個改變想法，決定其類型和優先級：
| 類型 | 使用時機 |
|---|---|
| 🔧 技能更新 | 問題來自技能的指令、輸出格式或預設行為 |
| 📋 專案/工作階段更新 | 上下文或指令僅限於特定專案、客戶或工作階段類型 — 非全域性 |
| 📝 Claude.md 更新 | 缺少適用於所有地方、所有專案和工作階段的上下文 |
| 💡 流程備註 | 行為改變 — 無需檔案編輯，只需改變工作方式 |
| 🆕 新技能 | 差距是反覆出現的，且大到值得為其建立一個專屬技能 |
專案/工作階段更新和 Claude.md 更新之間的關鍵區別在於範圍。如果上下文僅在處理特定專案、客戶或特定工作階段類型時才應適用，則它屬於專案/工作階段層級。如果它應該始終、無論在哪裡、為使用者進行的所有工作都適用，則它屬於 Claude.md。搞錯這一點的代價是雙向的：Claude.md 中的東西太多會在客戶之間造成干擾和上下文混淆；專案檔案中的東西太多則意味著每次切換專案時都必須重新設定上下文。
對於每個行動項目，說明要改變什麼、在哪裡改變、為什麼它很重要，以及是要立即執行還是記下稍後處理。在套用任何內容之前，請先確認：
「這是我提議要改變的內容。要我繼續執行嗎？」
關於每種類型更詳細的指導，請參閱 references/action-item-types.md。
第 6 階段 — 使用版本控制套用變更
使用「先複製再修改」的版本控制模式來套用每個已確認的行動項目——永遠不要直接覆寫原始檔案。規則：讀取當前內容 → 在記憶體中套用編輯 → 寫入新的版本檔名（例如 SKILL-v1.1.md）→ 將舊檔案保留在 archive/ 中。這樣可以在沒有獨立版本控制工具的情況下，建立可回復的歷史記錄。
技能更新： 讀取當前內容 → 在記憶體中套用 → 寫入新版本檔名 → 歸檔舊版 → 新增變更日誌條目。小幅修正請升 patch，有意義的補充請升 minor，架構變更請升 major。
專案/工作階段更新： 找出適用於該變更範圍的正確指令檔案——這可能是專案層級的 CLAUDE.md（位於 Claude Code 的儲存庫或資料夾根目錄）、一個 Cowork 工作階段設定、一個用於反覆進行的客戶參與的常駐簡報檔案，或針對特定工作階段類型自訂的指令。如果檔案不存在，請建立它。套用與其他檔案變更相同的「先複製再修改」模式。
常見目標：
[專案資料夾]/CLAUDE.md— 在該專案的每個 Claude Code 工作階段中自動載入- 一個
[客戶名稱]-brief.md或[專案名稱]-context.md常駐參考檔案 - Cowork 工作階段層級的設定或系統提示
- Claude.ai 自訂指令（帳戶設定 →「你想讓 Claude 知道什麼？」）
Claude.md 更新： 讀取當前內容 → 在正確區段新增上下文 → 寫入新版本 → 歸檔舊版。如果 Claude.md 不存在，請建立一個。
流程備註： 記錄在回顧快照中（無需獨立的檔案）。
套用完成後，確認變更內容：
「完成 — 已將 [技能名稱] 更新至 v1.1，並在 Claude.md 中新增了一條關於 [主題] 的備註。」
第 7 階段 — 儲存回顧快照並更新稽核日誌
此階段是強制性的——每次執行回顧都必須產生一個已儲存的快照，無論套用了多少行動項目。快照是記錄本身；稽核日誌則是資訊流。
步驟 1：儲存回顧快照
將完整的回顧快照儲存到已設定的 archive_dir。檔名格式：
[archive_dir]/YYYY-MM-DD-[簡短描述]-retro.md
範例：H:\My Drive\Retros\2026-05-15-doc-build-retro.md
保持描述簡短（3–5 個單字，用連字號分隔）：dashboard-build、content-draft、data-analysis-q2。
快照範本
# 回顧快照：[工作階段描述]
**日期：** YYYY-MM-DD
**工作階段類型：** [SOW 建構 / 資料分析 / 內容 / 程式碼 / 其他]
**使用的技能：** [逗號分隔清單]
**回顧格式：** [WWW / Start-Stop-Continue / 4Ls / 等]
---
## ✅ 做得很好
- [項目]
## ❌ 做得不好
- [項目]
## 🔧 討論過的改變想法
- [項目]
---
## 行動項目與結果
| # | 變更 | 類型 | 目標 | 狀態 |
|---|---|---|---|---|
| 1 | [描述] | 技能更新 | [技能] v1.0 → v1.1 | ✅ 已套用 |
| 2 | [描述] | 專案/工作階段更新 | [專案 CLAUDE.md / 客戶簡報 / 工作階段設定] | ✅ 已套用 |
| 3 | [描述] | Claude.md 更新 | Claude.md | ✅ 已套用 |
| 4 | [描述] | 流程備註 | — | 📝 已記錄 |
| 5 | [描述] | 新技能 | [名稱] | 🔜 待辦 |
---
## 流程協議
[本次回顧中達成的任何行為協議——雙方同意下次以不同方式處理的事項，且無法對應到檔案變更]
## 待解決問題 / 待辦事項
[記下稍後處理的項目、需要重新審視的事項，或本次回顧的後續行動]
## 備註
[任何值得保留的額外上下文]
步驟 2：更新稽核日誌
在儲存快照後，在歸檔目錄的 retro-log.md 中附加一行。這個檔案是運行中的資訊流——一個可快速瀏覽的、所有執行過的回顧記錄。
retro-log.md 格式（首次執行時以此標題建立）：
# 回顧日誌
所有 retro-bot 工作階段的運行記錄。
| 日期 | 工作階段 | 已套用 | 已記錄 | 待辦 | 快照 |
|---|---|---|---|---|---|
每次新的回顧附加為一行：
| 2026-05-15 | 文件建構 – 長篇提案 | 2 | 1 | 0 | [連結](2026-05-15-proposal-doc-retro.md) |
- 已套用：狀態為 ✅ 已套用的行動項目數量
- 已記錄：流程備註的數量（📝 已記錄）
- 待辦：標記為 🔜 待辦的項目數量
在儲存兩個檔案後，進行確認：
「回顧快照已儲存至
[archive_dir]/[檔名]，稽核日誌也已更新。您現在共有 [N] 次回顧記錄在案。」
語調與精神
- Claude 先發言 — 在徵求使用者的意見之前，先分享您的觀察。
- 要具體 — 「
.docx表格因為欄寬被寫死而無法正確渲染」比「檔案格式錯了」更有用。 - 小改變會累積 — 一個能為每次工作階段節省 10 分鐘的三行程式碼修正，很快就能累積出顯著的效益。
- 不是什麼都需要修正 — 兩個精準的改變勝過八個半吊子的改變。
- 保持快速 — 目標是 10–15 分鐘。如果時間拖太長，表示你正在回顧中解決問題，而不是在識別它們。把解決問題留到第 6 階段。
參考檔案
references/retro-formats.md— 其他格式：4Ls、Start/Stop/Continue、Mad/Sad/Glad、帆船法。當使用者要求不同的格式，或當多樣性比預設的 WWW 格式更能滿足工作階段需求時，請閱讀此檔案。references/action-item-types.md— 關於技能更新 vs. Claude.md vs. 流程備註 vs. 新技能的詳細指導。當行動項目的類型不明確時，請閱讀此檔案。
變更日誌
| 版本 | 日期 | 變更 |
|---|---|---|
| v1.0 | 2026-05-26 | 初始版本 — 完整的回顧工作流程、6 階段結構、先複製再修改的版本控制、回顧報告範本 |
| v1.1 | 2026-05-26 | 新增第 0 階段歸檔目錄設定（一次性設定，儲存至 Claude.md）、強制性回顧快照儲存、運行稽核日誌（retro-log.md）及每次回顧結果追蹤 |
| v1.2 | 2026-05-26 | 新增專案/工作階段更新作為一個獨立的行動項目類型——涵蓋專案 CLAUDE.md、Cowork 工作階段設定、客戶簡報檔案及 Claude.ai 自訂指令；釐清與使用者層級 Claude.md 的範圍區別 |
| v1.3 | 2026-05-29 | 遷移至外掛結構 (skills/retro-bot/SKILL.md)，新增 .claude-plugin/plugin.json 以支援 Claude Code |