pstack 解析：Cursor 工程師的 Agent 技能包

在 AI 輔助開發的討論中，多數工具都在追求「讓 Agent 寫出更多程式碼」。然而，曾在 Meta、Netflix 與 Cursor 工作的工程師 Lauren Tan（GitHub @poteto）開源的 Agent Skills 套件 pstack，卻走向了截然不同的方向。

pstack 收錄於 Cursor 官方外掛倉庫 cursor/plugins，採用 MIT 授權。Lauren Tan 在專案 README 開頭直截了當地定義其定位：

these are the same skills i use everyday to ship high quality code at Cursor. this turns cursor into a real engineering team. the goal is not to maximize loc, in fact it’s the opposite. pstack helps you write less, but higher quality code.

pstack 將資深工程師的工程紀律、決策標準與防禦性思維，編碼為一組 Agent 能嚴格執行的純文字規範，而非單純衝高程式碼產量。

什麼是 pstack：定位與三大常見誤解

理解 pstack 之前，必須先釐清三個常見誤解：

• 它不是框架或程式庫：整個套件由純 Markdown 檔案（skills/<name>/SKILL.md 與參考模板）組成，沒有任何執行檔相依性，因此 Claude Code、Codex、Pi 與 OpenCode 等 Agent 都能直接讀取。
• 它不是追求行數的加速器：作者明言「throughput without quality is not a goal i aspire to. if you want to go fast, go deep first」。在 pstack 的哲學中，品質先於速度，平行化（Parallelism）是建立深度驗證與信任後的副產品。
• 它沒有規劃類技能：作者不信任事前規劃，主張「the best spec is code」。需要規劃時，由 poteto-mode 內建的作業程序（Playbook）臨場處理。

既然 pstack 只是一疊純文字檔，也沒有規劃層，它靠什麼把工程流程、原則與多模型協作串成一套系統？答案在它的架構。

系統架構：入口、分類層級與可點名原則

截至 2026 年 10 月，pstack 收錄 51 項技能，其中 24 項是行為原則。串起這些技能的是統一入口 poteto-mode，以及寫在它裡面的 23 個 Playbook 與多模型調度規則。

統一入口：poteto-mode

日常操作中，使用者只需記住單一指令 /poteto-mode <任務>。這是具有黏性（Sticky）的模式（YAML frontmatter 標記 mode: true），在對話回合中持續生效。它的核心職責包含：

1. 路由到 Playbook：根據任務特徵從 23 個既定 Playbook（涵蓋 bug fix、perf、refactoring、investigation、shipping 等）中挑選合適流程，將標準步驟複製至待辦清單並逐步觸發相應技能。Playbook 是「怎麼工作的程序」，技能則是「程序中每一步的專家」。
2. 執行不可妥協的條款（Non-negotiables）：強制執行核心規範，例如定義邏輯前先確立資料結構（「name the data shape first」）、跨函式改動必須先經架構審查、自然語言說明與對話一律套用去贅字規範（unslop）。
3. 區分提問邊界：若問題可透過「執行程式碼並觀察結果（行為、時序、輸出、效能）」取得客觀事實，Agent 必須自行實驗而非詢問人類；僅有不可實驗的產品或偏好決策才需向人類請示。
4. 自治與中斷原則：可逆操作（如在團隊頻道發訊息、更新 ticket、啟動 eval）自主推進；唯有不可逆寫入（如強制推送共享分支、部署、刪除資料、發訊息給客戶）才暫停並取得確認。

子 Agent 與多模型協作

poteto-mode 規範了明確的調度原則：所有子任務皆於背景執行、傳遞檔案路徑而非在對話中內嵌全文（遵循 guard-the-context-window 原則），並依任務性質配置最適模型。

實際執行時，系統將任務分層：瑣碎且機械化的程式碼編輯交由快速模型處理，跨模組的架構設計與論述判斷則交給高推理能力模型。系統亦內建專屬角色，例如完整遵循原則索引的通用子 Agent poteto-agent，以及唯讀的程式碼註解審查者。

24 條核心準則：即時導正 Agent 行為

pstack 將資深工程師的直覺轉化為 24 條獨立原則，涵蓋核心思維、系統架構、驗證標準與委派紀律。每條原則皆以獨立技能檔案存在，除了任務啟動時由 Agent 讀取，使用者也能在對話中直接「點名」，作為即時行為修正器：

• 最小改動與質疑前提：如 laziness-protocol（偏好刪除與最小修改）與 attack-the-premise（當多個解法卡在同一關卡時，先質疑共同前提）。
• 結構化領域與邊界守衛：如 model-the-domain（以型別表達領域，消除散落的條件判斷）與 migrate-callers-then-delete-legacy-apis（在同一波變更中遷移呼叫端，並立即刪除舊 API，不留脆弱相容層）。
• 真實產物驗證：如 prove-it-works（對真實產物驗證，拒絕以 Proxy 等替代品或自述充當證據）與 test-behavior-not-implementation（「若每個被 import 的函式回傳 undefined 時測試仍然會過，重寫斷言或刪掉這個測試」）。
• 後設編碼原則：encode-lessons-in-structure——當發現自己在寫第二次相同的指示時，將其編碼為 Lint、型別約束、執行期檢查或腳本，而非更多自然語言文字。

核心技能解析：從理解、平行到品質與驗證

在 pstack 內建的技能庫中，最具代表性的是以下四大模組：

理解模組：how、why 與 blast-radius

• /how：針對跨檔案或複雜架構，平行派出 2 至 4 個唯讀探勘子 Agent，最終由統整者輸出如資深工程師親自引導般的架構解析。
• /why：透過版本控制紀錄（git blame 與 git log）建立程式碼錨點，並透過外接 MCP 工具平行查詢多類歷史證據（Issue、文件、通訊紀錄），回溯設計決策背後的權衡。
• /blast-radius：評估修改帶來的影響範圍。其核心為五級確定性階梯（從單純陳述、指出具體行號、走查失敗路徑，到撰寫腳本呼叫真實程式碼與在執行環境中重現）。Agent 必須主動由低階推向高階，並找出「改動之所以安全的那一個關鍵事實」（the one fact it’s safe because of），消除空泛的猜測。

平行模組：arena 與 swarm

兩者皆利用子 Agent 進行平行擴展，但設計目的與裁決機制完全不同：

品質模組：unslop 與 no-comments

• /unslop：定義了編號穩定的去贅字檢查清單，過濾空泛動詞、無意義轉折與套版句型，專注於維持高資訊密度與精確語意。此規範強制適用於任何散文文字，包括技術文件與 Agent 自身的回覆。
• /no-comments：派遣專屬審查者清除無效註解，並將真正具有約束價值的註解轉化為型別系統、執行期檢查或 CI Lint 等具體程式碼結構。

驗證模組：create-verification-skill

/create-verification-skill 是 pstack 最具深度的核心資產。其設計宗旨為「為下一個從未見過此專案的 Agent 撰寫驗證技能」。

生成的驗證技能固定包含六大標準章節：Launch（明確啟動指令與就緒判準）、Doctor（唯讀健康檢查，確保環境未帶病測試）、Drive（操作介面的真實 Selector）、Evidence（走真實使用者路徑、連副作用一起驗證，不以自述代替證據）、Cleanup（精確清理行程，避免殘留行程污染系統環境）與 Helpers（隨附腳本必須可直接執行，呼叫方式寫進技能本體）。

在交付之前，Agent 必須親自以該技能執行端到端驗證，落實這條紀律：「未經執行的驗證技能僅是草稿而非交付物」。

設計哲學：貫穿 pstack 的五大決策

1. 純 Markdown 實現：作者在 verification-skill-example 的 README 寫道：「A wiki is great for humans. Agents pay for every token they reread.」pstack 沒有任何聰明的執行環境，聰明全在文字裡：既節省 Context，也因此可以移植。
2. 分層信任體系：約束機制的可靠度由強到弱依序是「架構 > 靜態分析／CI > Lint／編譯器 > 規則／技能」。寫成文字的規則最弱，Agent 也容易遺忘，因此 pstack 盡可能把要求推向可執行的檢查，例如 no-comments 把註解改寫成型別或 Lint、驗證技能的 Doctor 健康檢查。
3. 寫作者與驗證者嚴格分離：驗證者不能由撰寫程式碼的 Agent 兼任；/arena 的裁判與 /interrogate 的審查者都換成不同模型家族。作者的說法是：「The adversarial signal comes from model diversity, not assigned personas」。
4. 重塑人類的角色定位：人類不再是每一步驟的審查瓶頸，而是轉為「事後糾偏者」與關鍵決策的仲裁者。
5. 系統的自我迭代：透過任務反思機制（reflect）將除錯經驗寫回技能庫，使系統隨著失敗案例持續演進。

實務建議：一般團隊的漸進導入路線

不必一次裝完整套件。想借鑑 pstack 的團隊，可依投資報酬率由高至低逐步引入：

1. 採用驗證技能的標準結構：依據 Launch、Doctor、Drive、Evidence、Cleanup、Helpers 六節結構，為自身專案建立專屬的 Agent 驗證指引。
2. 導入確定性階梯與單一安全事實：在程式碼審查時，要求 Agent 標明結論所屬的驗證層級，並指出變更安全的關鍵論據。
3. 為無人值守任務寫合約（Overnight Contract）：交代目標、可證偽的完成條件、預先授權的權限與逃生口四項要素。注意「a duration is not a finish condition」：「跑一整晚」不算完成條件。
4. 將核心原則寫入專案規範：挑選 3 至 5 條高度認同的原則（如 laziness-protocol、prove-it-works）加入 AGENTS.md，並於日常對話中直接點名引用。
5. 套用去贅字（unslop）清單：用來把關自己與 Agent 的文字輸出。
6. 完整套件：以上都用順了，而且你的工具支援子 Agent 與背景任務，再整包安裝、改走 poteto-mode。

README 簡介以一句話收尾：「fork it. improve it. make it yours. PRs are welcome!」pstack 最有價值的讀法，不是當成待辦清單逐條照做，而是當成一份高解析度的樣本：看一位資深工程師如何把「什麼算做完、什麼算安全、什麼該問人」寫成 Agent 讀得懂的文字。