pstack 深度導讀（下）：55 個技能、代理提示、自動化與程式檢查

pstack 深度導讀（上）畫出 repo 的整體結構，pstack 深度導讀（中）走過 23 份 playbook 和 24 個原則。這篇逐項看剩下的通用技能，再往下讀代理設定、Benny、自動化提示範本、參考檔和腳本。

研究固定在 pstack 0.15.26。這個版本共有 55 份 SKILL.md：31 個一般技能和 24 個原則。中篇已逐項分析原則；以下 31 項都說明何時使用、它安排 Agent 做什麼，以及它依賴哪些能力。

先用四個問題讀一個技能

讀 SKILL.md 時，不要只看名稱或它寫得多嚴格。先找：

1. 觸發條件：使用者要說什麼，或任務具備什麼特徵，它才適用？
2. 輸入資料：它需要讀哪些程式、對話、模型設定或外部狀態？
3. 執行方法：它要求 Agent 做哪幾個動作，會叫用哪些其他技能？
4. 停止與驗證：什麼情況要停住？要看什麼實際證據才能回報完成？

以下的「限制」不是說技能沒用，而是指出提示本身不會替宿主補上工具、權限、資料或外部檢查。

31 個一般技能逐項解析

了解程式、歷史和任務

1. how 在你問「它現在怎麼運作、責任該放哪裡」時使用。它先找程式入口和資料流，複雜問題可把不同讀碼角度交給唯讀 explorer，再由 explainer 整合；若問題是設計動機，改走 why。子代理若不能用需要的 MCP，就無法代替 why 的歷史證據。

2. why 調查設計理由、回歸背景、閾值或事後檢討。它依證據來源分派調查，再要求 synthesizer 區分直接證據、支持、推論、猜測和未知；沒有連到的 issue tracker、聊天或監控系統，要列為未涵蓋的來源。

3. teach 把複雜系統解釋到讀者能建立心智模型。它把 how 的執行機制和 why 的設計背景組合起來，依讀者已知程度安排說明；如果小問題硬跑完整多來源調查，成本會高於需要。

4. recall 用來接手過去工作。它限制主題和時間範圍讀 transcript，再以 Git、PR、ticket 等當前狀態核實舊主張；只看聊天紀錄不算確認目前 branch 或 PR 狀態。

5. poteto-help 回答「我要用哪個技能、playbook 或怎麼設定 pstack」。它讀技能描述和使用指南，再提供可以直接交給 Agent 的任務提示；它是導覽，不會代替你啟動被推薦的工作。

6. sharpen 在工作開始前重新檢視使用者真正想解決的問題、需要哪些原始資料和外部正確性檢查。它要求直接進入工作，但不代表有權限替使用者決定不可逆的產品或資料選擇。

7. in-your-own-words 只重述使用者目標和想解決的問題。它適合檢查意圖有沒有聽錯，不等於範圍、完成條件或授權已經談妥。

8. bro 把上一則訊息改寫成更白話的說法。它不會補資料或驗證事實，因此簡化後仍需保留原本的技術意思。

9. ketchup 整理使用者上次發言後的重要進展和所有待決事項。它要求 read-only 查即時狀態，並把每一個待決選項寫到讀者能直接判斷；它不執行待辦工作。

設計、分工與除錯

10. architect 適合可能因型別、資料結構或 module 邊界選錯而難以修改的工作。它先用 how 建立現況，再比較候選介面和責任；任務若只是機械式修改，完整設計流程會過重。

11. arena 讓多個候選獨立解同一個設計問題，再依事先定好的 rubric 選底稿、移植有價值的部分並驗證。題目或評分準則模糊時，跑更多候選只會得到更多彼此不同的猜測。

12. figure-it-out 是大型遷移、多階段交付或既有 playbook 不合用時的流程設計器。它從完成條件與最大未知開始，安排可檢查的工作單位和決策紀錄；如果已存在合適 playbook，不該再套一層自訂流程。

13. blast-radius 追查 diff 以外可能受影響的呼叫者、資料契約、生命週期與整合。它要求拿程式、測試或執行中的產品證明關鍵安全事實；只列出可能影響而沒有實際驗證時，結論仍是未證明。

14. interrogate 在使用者要求對抗式、多模型審查時啟動。多位 reviewer 依 diff 和意圖尋找問題，lead judgment 再把結果分類為要修、考慮、記錄或駁回；多數 reviewer 同意不等於發現正確。

15. correct 處理操作人至少兩次糾正的同一類錯誤。它先讀近期 commit、revert、review 和 workaround，再依序考慮架構、型別、lint/CI、測試，文件最後補位；每個新檢查都要拿真實舊錯誤證明能失敗。

16. swarm 為覆蓋率、分片或競賽問題安排多個 worker。它先定交付條件與分工形狀，再收集結果、核對 SHA 和證據；子代理說自己完成，不代表主 Agent 已核實其產物。

驗證、效能和型別

17. benchmark-checklist 在回報效能數字前檢查測量方法、限制因素、錯誤、樣本和可重現性。關鍵工作根本沒執行、環境不公平或量測無法分辨差異時，要回報 inconclusive，而非挑最好看的數字。

18. tdd 只在使用者要求 TDD/回歸測試，或 bug 有清楚且便宜的測試路徑時使用。它先以可觀察行為寫一個會因正確原因失敗的測試，再修實作；測試昂貴、脆弱或牽涉大型整合環境時，改用最接近的真實驗證。

19. create-verification-skill 為沒有自動操作方式的 UI、CLI 或服務建立專案專屬驗證技能。它要找出啟動方式、使用者路徑、觀測證據與清理方法，然後真的跑一次；只有文件、沒有跑過的技能還是草稿。

20. create-formal-verification-skill 把高代價、測試難觸及的不變條件寫成模型或形式驗證。它要求指出模型對應到哪些程式、聲明界限，並在故意破壞的不變條件上證明檢查會失敗；通過只能支持該模型和範圍，不能說整個系統已證明正確。

21. maintain-verification-skill 定期核對專案的 feature map 與驗證技能是否還符合現行產品。它先讀來源，再用同一個可操作產品逐項驗證；某個功能碰不到就標成 blocked，不能把未測到說成通過。

22. typescript-best-practices 在讀寫 TypeScript 時提供判別聯集、品牌型別、外部資料解析、schema 型別和測試等慣例。它需要配合 repo 的實際型別和 schema；brand 不可只靠 as 假裝檢查過。

寫作、偏好與個人流程

23. automate-me 從目前 workspace 的近期對話整理反覆出現的個人工作偏好，再產生 mode skill 草稿。它要求把 transcript 限定在指定 workspace，也會將判斷交給使用者迭代；一次出現的偏好不應寫成長期規則。

24. make-bot-ui 建立能透過 webhook 喚醒 Grok Bot 的本機小介面，並要求把 key 放在伺服器端而非瀏覽器。這項工作依賴 Cursor Automation、secret request、Tailscale 等外部能力；技能文字不能取代真正的憑證存放和 webhook 權限設定。

25. no-comments 讓 Comment Sicko 檢查特定 diff 的註解、lint suppression 和 workaround。主 Agent 要核對判斷並找能讓程式本身說清楚的修正；法律註記、公有 API 契約和必要 suppression 等例外仍需檢查，不能機械全刪。

26. show-me-your-work 為長期或無人監看的工作記錄每個重要決策、原因、證據和結果。它附有 TSV template 和寫入 script，預設不提交；簡單任務不必硬做成日誌專案。

27. technical-writing 依文章目的選 tutorial、how-to、reference 或 explanation，再套句子清楚、符合讀者任務的寫法。不同文類規則不同，不能把乾燥 reference 的標準套到教學文章。

28. unslop 移除空泛詞、冗語、AI 慣用轉折、抽象隱喻和機械化格式。它是文風自檢，不是逐詞取代器；替換時要保留技術精確度和作者語氣。

29. reflect 從當前對話找值得長期保存的教訓，讓多種 reviewer 分別找不同類型的重複問題，再由 synthesizer 決定候選是否耐久。已接受的技能修改仍要交使用者批准，不能把一次失誤自動升格成規則。

30. setup-pstack 設定模型角色與推理預算，檢查可用 model slug 後寫入個人規則檔。它會修改使用者設定，因此應核對變更內容；上游預設不是長期相容保證，Cursor 帳號也未必能用每一個模型。

31. poteto-mode 是工程工作主入口與工作風格規則。它列出路由條件、24 個原則、子代理分工、驗證和交付要求；內容很密集，因此實際效果也會受 playbook 是否完整載入、MCP 和子代理是否存在所影響。

這 31 項不是同一種東西：how/why 取得不同證據，architect/arena 比較方案，驗證技能建立實際檢查，bro/ketchup 整理對話，setup-pstack 改使用者設定，而 poteto-mode 安排整體工作。觸發條件越精確，路由時越容易選對；副作用越大，越需要宿主的工具權限提供控制。

自訂代理提示：主代理和子代理分別負責什麼

pstack 另有兩個代理描述檔：

• poteto-agent 負責程式撰寫和輔助任務。父 Agent 擁有 todo、playbook 和委派決策；子代理要先讀 poteto-mode 並只完成分派範圍。這是工作角色規定，不會自動把子代理變成唯讀。
• comment-sicko 用強烈的語氣找可刪除的註解和 workaround，但也列出法律標頭、公有 API 註解等例外。它的提示沒有設定 readonly: true，所以「代理說自己只審查」不能證明宿主禁止它寫檔。

這正好說明必須分開看「Agent 被要求做什麼」和「它被允許做什麼」。代理 prompt 是角色指引；唯讀權限要由 Cursor 子代理設定或其他執行環境提供。

參考提示把複雜工作分成幾段

SKILL.md 旁邊的 references 不是新的 slash skill，而是上層流程交給子代理或主 Agent 的工作材料。這些檔案通常固定輸入、問題和輸出格式：

• architect 有設計紅旗、rationale template 和 runner prompt，讓候選方案從呼叫者用途出發，再由主流程比較。
• how 有 explorer 與 explainer prompt，前者切片讀程式，後者合併結果並回到來源檢查矛盾。
• interrogate 有 reviewer、rubric、code-quality lens 和 lead judgment；評分項目提供審查角度，lead 仍要核實證據，不能多數決。
• reflect 有 divergent、judgment、tooling reviewer 和 synthesizer；它將學習候選與實際技能修改分開。
• why 有 source playbook、epistemics、investigator prompt 和 synthesizer prompt，分別處理來源覆蓋、證據分級和結論合併。
• typescript-best-practices 有 pattern 範例；poteto-help 有 prompting 與 recipes；show-me-your-work 附決策紀錄範本。

Prompt chain 的可靠度取決於上下游真的有傳遞背景、找到正確版本檔案並核對產物。只看到 prompt template 存在，不代表呼叫者一定有跑它。

Benny 是要安裝與設定的自動化素材

pstack/automations/benny 有 12 個檔案，包括安裝說明、FOR_AGENTS.md、三個操作技能、參考設定、範例 routing/config，以及兩份 automation prompt template。它設計兩條 Slack 問題回報流程：

1. Triage：收到回報後分類、查是否重複、路由到正確 owner 或 tracker。
2. Reproduce and fix：在指定介面重現已確認 bug、先驗證既有修正、必要時才改程式並提供證據。

但 Benny 不會隨 pstack 安裝就監控 Slack。要用它，得先把檔案複製進專案指定位置、填實際工具和 tracker、配置必要資訊，再由人建立與啟用 Cursor Automation。Slack、issue tracker 和 PR 的寫入能力仍來自那些外部服務的帳號權限。

README、使用指南和自動化檔案各自負責什麼

pstack 還有一份 README，列安裝方法、模型預設、23 份 playbook 索引與各技能入口。它是套件地圖，不是所有執行路徑的完整規格。

新手指南 把內容排成十個章節，依序帶讀者完成：

1. 安裝與設定模型。
2. 把任務交給 poteto-mode 路由。
3. 改程式前先理解現況。
4. 在寫程式前先做設計選擇。
5. 依任務選 build playbook 並整理 diff。
6. 驗證結果並開 PR。
7. 安排可稽核的過夜工作。
8. 用原則名稱改變 Agent 的取捨。
9. 建立自己的工作模式與技能。
10. 常用範例與容易犯的錯。

Benny 的 12 個檔案也各有分工：

兩份 manifest 控制安裝名稱和元件路徑，LICENSE 說明重用條件，.gitignore 排除本機產物；assets 和指南圖片只供說明使用。這些檔案不會自行執行。Claude Code adapter 則是生成另一個發行副本時使用的工具轉譯表。

腳本與 CI 實際能擋住什麼

pstack 不只有提示，也有程式碼，但每個檢查仍有明確範圍：

• check-plan.mjs 檢查多階段計畫的結構和必填欄位。它不能判斷每個計畫內容是否正確。
• orch 與 store 管理協調所用的持久資料和狀態，讓大型工作能在重啟後讀回進度。它本身不是模型、Task scheduler 或權限服務。
• watch-pr 讀取 PR、CI 和 review 狀態，按明確規則分類並輸出。它整理證據，不是 GitHub 的分支保護規則，也不會因 prompt 要求就奪走 Agent 手上的 merge 權限。
• worktree-audit.sh 盤點 worktree 大小、狀態和線索，供人或流程挑選候選清理項目；它不是自動刪除器。
• generate-pstack-harness-trees.mjs 把 Cursor 原始套件轉成 Claude Code 發行副本，檢查名稱、adapter 對照和同步結果；repository CI 會以 --check 驗證產物一致。

這裡可以看到三種不同強度：文件要求 Agent 執行某個動作、腳本檢查一組明確條件、外部平台限制帳號能做的事。腳本只有在檢查規則本身可信、執行它的入口沒有被任務 Agent 任意改寫時，才形成穩定的 gate。pstack 的產生器 CI 強制副本同步，卻不會強制 Agent 在每個任務都走完驗證流程。

如何從 pstack 設計自己的工作流程

pstack 值得借鏡的不是檔案數量，而是它把角色分開的方式。你可以從一個常見任務開始：

1. 寫出任務的觸發條件，以及使用者如何判斷完成。
2. 建一個主入口，只負責選流程和保存工作狀態。
3. 每種長工作有自己的步驟、輸入、停止條件與證據。
4. 重複使用的操作拆成技能；反覆出現的決策做成原則索引。
5. 委派時寫清楚子代理輸入、檔案範圍、可用工具和回報格式。
6. 能用程式檢查的條件做成 script 或 CI，並拿真實錯誤證明檢查會失敗。
7. 檔案、網路、Git 和正式服務權限由宿主與外部服務設定，不靠 SKILL.md 自稱唯讀。
8. 用幾個真實任務測試路由，也保留無法重現、工具缺失和資料不足的停止路徑。

不要一開始就做 55 個技能。先觀察哪個錯誤重複發生，再選最能降低錯誤的結構。pstack 的 /correct 把這條路徑寫成架構、型別、lint、測試、文件的順序；新增加一段提醒通常是最後才選的手段。

三篇的閱讀路徑

• pstack 深度導讀（上）：一個工程 Agent 外掛的完整地圖 說明 repo 零件與宿主邊界。
• pstack 深度導讀（中） 示範任務怎麼流過 playbook、技能與原則。
• pstack 深度導讀（下）：逐項拆解可重用材料。

研究範圍是 pstack 0.15.26 的文字、程式和產生器。我沒有執行每一條 playbook，也沒有測量不同模型的成功率；文件寫出的流程是可觀察的設計，不能單靠本文推論它在所有 repo 或模型上都會照樣運作。