retro

retro 概覽

retro 是做什麼的

retro 是給工程團隊用的專案回顧 skill。它會把 commit 歷史、近期時間軸資料和先前學到的內容整理成每週回顧，回答「我們交付了什麼？」以及「上一個 sprint 發生了哪些變化？」如果你需要的是會產出結構化團隊檢視，而不是泛泛的狀態摘要的 retro skill，這就是適合的選擇。

適合誰安裝

如果你想要一個可重複使用的 retro guide，用在每週工程檢視、sprint 結束回顧，或主管 check-in，retro 很適合。它特別適合 Project Management 工作流程，因為你會需要精簡的進度表述、每個人的貢獻訊號，以及跨週趨勢的掌握。

它有什麼不一樣

這個 skill 的核心是持續記憶，而不是一次性的 prompt。它會讀取先前的 retros、最近的 timeline 事件，以及最近的 learnings，所以每次執行都能延續前一次的脈絡。當你在意的是推進力、延續性問題，以及團隊是否真的在隨時間改善時，這會特別有用。

如何使用 retro skill

安裝並觸發 retro skill

安裝方式：
npx skills add garrytan/gstack --skill retro

之後，當你需要週回顧、交付摘要，或 sprint review 時就可以呼叫它。這個 skill 裡最自然的觸發語句包括「weekly retro」、「what did we ship」以及「engineering retrospective」。

給它正確的輸入

如果你的 workspace 已經有 commit 活動，而且專案目錄也維持一致，retro install 的決策通常最容易。要得到最佳結果，請先把時間範圍、團隊，以及任何重點領域直接告訴 agent。例如：「請回顧最近 7 天，強調 release blocker，並點出 ownership 變動。」這比單純說「總結這個專案」更好，因為它能明確告訴 skill 要怎麼框定輸出。

先讀這些檔案

先看 SKILL.md，了解工作流程與限制；如果你想看生成文件是怎麼組裝的，再檢查 SKILL.md.tmpl。由於這個 repo 沒有附帶 rules/、resources/ 或 scripts，這兩個 skill 檔就是主要的事實來源。

實務工作流程建議

retro 最適合在完成一個有意義的工作週期之後使用，而不是做到一半就跑。如果你的 repo commit 很稀疏，輸出會比較薄弱，所以可以補上更明確的日期範圍，或要求和先前 retros 做比較。若是用在 Project Management，請要求結果、風險與下一步行動，而不是敘事式的回顧摘要。

retro skill 常見問題

retro 只適合工程團隊嗎？

大致上是。retro 的設計是圍繞 code changes、工作模式與交付訊號，因此比起一般商務報告，更適合工程情境。如果你的專案沒有有意義的 commit 軌跡，這個 skill 可用的素材就會少很多。

它和一般 prompt 有什麼不同？

一般 prompt 可以一次總結一週。retro 則是一個可重複使用的 skill，內建會查詢先前 retros、timeline events 與 learnings，因此能產生更一致的每週輸出，並且追蹤長期脈絡。

retro 適合新手嗎？

可以，只要你能描述回顧期間，以及希望強調的重點就行。你不需要知道內部機制也能使用這個 skill，但輸入越完整，retro 品質通常越好。新手最容易得到好結果的方式，是明確指定日期範圍、團隊，以及一到兩個重點面向。

什麼情況下不該用 retro？

如果你要的是深入的架構審查、bug triage 報告，或產品策略備忘錄，就不要用 retro。它最適合團隊進度回顧與能看出趨勢的 retrospective，不適合拿來做橫跨無關目標的廣泛分析。

如何改進 retro skill

先把回顧問題定清楚

最好的 retro usage，通常是先從清楚的問題開始：交付速度、ownership、品質，或團隊健康。如果你一次要求全部內容，retro 很容易變得很泛。請先選出你讀完之後真正要做決策的那一件事。

提供更好的事實基礎

把日期範圍、repo name、release milestone，以及已知 incident 一起給 skill。例子像是：「上週的主要目標是 release readiness；請標出 regression、handoff 與尚未完成的工作。」這樣能幫助 skill 分辨真正的進展，而不是表面上的忙碌。

注意常見失敗模式

最常見的失敗模式，是過度重視 commit 數量，而不是有意義的進展。另一個問題是空泛的讚美，反而把風險遮住。如果第一次輸出太寬，可以要求更細的切分：已交付項目、受阻項目、團隊貢獻，以及下週風險。

用追問來迭代

第一次 retro 跑完之後，可以用一個追問來修正方向：「重新跑一次 retro，更多強調 code quality 和尚未結案的 follow-up」或「把這份內容用 PM 受眾能看懂的方式濃縮成五點。」這通常比從頭重來更有效，也能讓 retro skill 更貼近你實際的工作流程。