把 Agent 的能力加到 19 項，看起來像是一台新機器終於裝滿了工具；實際上，這通常是把 19 個新的資料來源、安裝路徑、權限邊界與失敗模式一次搬進系統。真正該問的不是「還缺哪個 Skill」，而是：它替這週反覆出現的哪一個痛點，交付了哪個可驗收的結果？
@painn_x 的〈19 Skills I Would Install on a Fresh Hermes Setup〉把搜尋、真實瀏覽器、repo memory、工程流程、影音、寫作與多 agent 編排放進同一份清單，並建議不要在第一天全部安裝。這是合理的起點，但「晚點再裝」還可以更精確：每個新增能力都應是一份小型工作契約，而不是一張收藏卡。
這篇不是 19 個 repository 的轉貼。它提供一個能用在 Codex、Claude Code、Hermes 或任何可讀取本地指令的 Agent 上的採用門檻：先證明痛點，再限制權限，最後留下可以拒絕壞結果的證據。
一個 Skill 改變的不只是回答方式
Skill 最常見的形態是指令、範本與輔助資源的資料夾；它能讓 Agent 在適當任務中採取一致流程。這個形式很輕，但後果可能很重。以原文提到的類型為例：
| 能力類型 | 它可能新增的邊界 | 失敗時真正的代價 |
|---|---|---|
| 網路研究與內容擷取 | 外部來源、登入態、資料保存 | 以過時或未授權資料下判斷 |
| 真實瀏覽器自動化 | 已登入帳號、下載與表單 | 非預期地代表使用者操作服務 |
| repository memory | 專案內容、跨 session 摘要 | 舊決策或敏感資訊被錯誤帶回 context |
| 工程流程與 review | 測試、版控、發佈命令 | 在錯誤 repo 或未驗證變更上執行副作用 |
| 外部 App 整合 | OAuth、觸發器與第三方資料 | 權限比任務所需更大，難以回收 |
例如，Browser Harness自述目標是讓模型透過瀏覽器完成任務；Agent-Reach則把多個公開內容來源與診斷流程打包。它們不是「更好的 prompt」：前者牽涉瀏覽器 session，後者牽涉來源路由與環境設定。要不要採用，應由邊界與證據決定，而不是 star 數或清單順位。
採用前只填四欄
每次想新增 Skill，先用下列格式寫一張卡。若其中任何欄無法填寫，就先不要安裝；這不是保守，而是把模糊需求留在無副作用的研究階段。
pain: 每週兩次需要從同一組公開文件擷取可追溯的摘要
capability: 將網址轉成正文 Markdown，保留來源 URL
boundary:
reads: 公開網頁
writes: 無
credentials: 不需要
evidence:
- 同一篇文件可重跑，且能連回原始來源
- 失敗時回報無法取得，不用摘要補猜
remove_when: 連續四週未使用，或既有工具已能產出同樣證據這四欄也能分出三種完全不同的需求。只需讀公開文件時，先用既有的 web reader 或一個受限的擷取工具；需要網站上的互動時，建立專用瀏覽器 profile，並把會送出資料的步驟留給人核准；需要跨 session 記憶時，先定義哪些決策可以保存、多久失效、如何刪除。不要因為它們都叫「research」或「memory」就交給同一個權限很大的插件。
先從只讀能力開始，讓痛點決定順序
原文的 Day 1 建議涵蓋網路研究、影音、文字與回覆風格。對工程團隊而言，我會再按副作用排序，而不是按功能分類：
- 只讀、可重跑的能力：例如清理網頁正文、取得公開文件或產生逐字稿。確認輸出能保留原始 URL，並用兩個真實任務檢查品質。
- 本地、可驗證的能力：例如對 repository 執行格式化、測試或 review。先沿用專案既有命令與規範，不要為了裝 Skill 另建一套流程。
- 持久狀態：例如記憶與任務看板。只儲存可以說明來源與有效期限的決策；「方便」不是把整段對話或機密塞進長期記憶的理由。
- 可代表使用者行動的能力：瀏覽器控制、App 整合、排程與安全工具。最後才接，設定最小 scope，並在發信、發文、付款、刪除或變更權限前停下來核准。
這個順序和原文的安全提醒相容：分離 browser profile、先讀安裝腳本、不要把 secrets 放進 prompt 或 log，並優先考慮 local-first 工具。它也避免一個常見誤判：把「Agent 能做」當成「Agent 現在應被允許做」。
不要同時裝兩套相同的工程儀表板
原文把 Addy Osmani 的 agent-skills、Matt Pocock skills、任務看板與多 agent 編排列為不同選項。它們都可能有價值，但在同一個 repository 同時引入兩份規則，最常見的結果不是雙倍品質，而是兩個 Agent 得到相衝突的「完成」定義。
先選一個目前缺口最明確的能力包，然後用一個小任務驗收。例如已有清楚的 test、check 與 review 流程，就不必再安裝完整的工程生命週期套件；真正缺的是跨 session 找不到先前決策，才評估記憶方案。本站先前的 Harness Engineering 已經把 context、state 與 memory 分開：memory 被寫入，不代表它應自動變成下一輪 context。
這也是我和「先裝滿再篩選」不同的地方。能力重複時，優先刪掉一個，而不是增加路由器、優先序與同步機制來管理兩個。只有兩套工具各自提供無法替代的證據或邊界時，才值得共存。
每月做一次移除測試
採用不是永久承諾。每月挑一個 Skill，暫時停用後跑同一類真實工作；比較交付時間、失敗率、人工介入次數與證據品質。若沒有可觀察的退步，就移除它。若有退步，將原因寫回四欄卡，而不是只記「很重要」。
這和 Skill 不會死：把 Agent 指令縮成可驗證的方法 的結論一致：模型越強，越應刪除重複描述通用能力的文字；留在系統外的，應是模型無法自行猜到的資料範圍、權限、證據與停止規則。
今天不需要重建整套 Agent。選一個本週真的卡住的重複任務，填完四欄卡，先給它只讀的最小能力。兩次可重跑的成功之後，再決定要不要把它升級為可寫入、可記憶或可代表你操作外部服務的工具。