Agent Skills

Agent Skills 是把可重複工作封裝成 agent 可載入、可執行、可評估的能力單位。它介於 agent-instruction-files 和 loop-engineering 之間：指令檔提供常駐專案背景，skill 則提供特定任務的步驟、工具、範例、限制與驗收方式。

核心判準

AIHAO 這篇文章整理 Anthropic 與 OpenAI 的方法論後，重點不是「多寫幾個 prompt」，而是把 skill 當成可治理 artifact。好的 skill 應從真實重複任務萃取，描述何時觸發、要讀哪些檔、執行哪些工具、如何處理錯誤，以及完成後要用什麼 evidence 判斷成功。這讓 skill 成為 harness-engineering-for-ai-coding 的 feedforward 層，而不是取代 tests、hooks、review 或 eval 的萬能設定檔。

建立流程

最小流程是：先手動跑一次任務，保留成功 transcript 與輸出；再請 agent 把過程濃縮成 skill；接著在相似但不同的案例上試跑，收集失敗；最後把修正、例外與驗收條件寫回 skill。這和 ai-collaboration-compounding-workflow 的複利邏輯一致：每次修正都應回流成下次可用的工作流記憶，而不是散落在一次性對話裡。

知識來源與萃取路線

AIHAO 2026-07-06 的新文把「專家的知識現在存在哪裡」拆成六條路線；這個框架已獨立整理成 knowledge-to-skill-framework。重點不是把所有來源混成一套，而是先判斷知識來源與成本結構，再決定要把它寫成 agent-instruction-files、SKILL.md、scripts/、references/ 還是 eval。

最穩的原則是：能寫成程式碼的明確規則就寫成程式碼；依情境判斷的隱性知識放進 skill；品質標準不要硬塞成 prompt，而是盡量做成 eval。這和 harness-engineering-for-ai-coding 的分工一致：skill 是知識容器，不是把所有東西都往上下文裡堆。

評估方式

Skill 的品質要用任務級 eval 看，而不是只看文字是否完整。AIHAO 引用的做法是準備代表性案例、定義成功／失敗 criteria、記錄失敗類型，並比較加入 skill 前後的成功率、成本與可維護性。若 skill 只是讓 context 變長、增加工具誤用或降低 model-harness-fit，就應刪減；ponytail 判準是「每週重複或高風險且有驗收 gate」才值得 skill 化。

與 MCP 的邊界

AIHAO 後 MCP 文章把 skill 的適用邊界說得更清楚：在 coding agent 能直接使用 shell、CLI、檔案系統與小腳本時，skill 通常比 MCP 更輕、更少 token，也更容易維護。MCP 仍適合 OAuth / API key 管理、有狀態 session、通用工具標準化與快速變動文件的 single source of truth；若 MCP 只是包一層 CLI，應優先改成 skills-vs-mcp 的 skill + script 模式。

對 AI Ark loop 的含意

AI Ark 不需要把所有 wiki 操作都拆成新 skill；目前只有 watch / ingest / verify 這種重複、有明確檢查點、且會因遺漏步驟造成資料腐化的流程值得保留。新 skill 應先證明能降低漏更新 index/log、raw hash 漂移或 broken wikilink，而不是為了看起來像 agent framework 而新增。

非工程師 Agent 的工作流拆解與 ROI gate

BusinessNext 訪談凱鈿 HR 經理 Wesley，補上一個適合非工程師的工作流設計判準：AI Agent 可視為「微型組織設計」，先區分能執行動作的 Tool 與承載任務方法的 Skill，再把大任務拆成有目標、步驟、資料與檢查點的子流程。這把 agent-ready-data-governance 的資料可用性要求接到 loop-engineering 的執行面。

最小拆解法是先定義最終 Output，再反向推回每一步所需的 Input；每一步的輸出都應成為下一步的輸入。發生錯誤時不要只改最後結果，而要找出日期格式、資料轉換或工具操作等流程斷點，將檢核寫回 Skill。最後用「每月執行次數 × 每次省下分鐘數」估算收益；若梳理與維護 Skill 的成本高於省下的時間，就不應把任務 skill 化。這是 loop-engineering 與 ai-code-validation-bottleneck 共用的最小化 gate。

跨產品格式與觸發

BusinessNext 對 ChatGPT Skills 的整理補充了可攜格式與使用邊界：SKILL.md 可搭配 references、templates 與 scripts，並以 @ 明確呼叫或依名稱與描述自動觸發。這強化了 skill 的最小設計原則：流程與品質標準放在 skill，專案歷史與檔案脈絡放在 Project；跨產品移植仍要手動安裝、檢查外部腳本並通過權限與安全掃描。

BusinessNext 2026-08-13 的訪談把這套格式延伸到非工程師與跨模型驗收：Skill 是至少包含 SKILL.md 的資料夾，可把參考資料、範本與程式放在同一個工作包；觸發可以由人明確指定，也可以由模型依名稱、用途與具體場景自動判斷。可重用的最小路徑是先找出重複三次以上、流程穩定且有完成標準的工作，先寫一份完整主 Skill 跑通，再在步驟過於複雜、經常失敗或需要跨任務重用時拆成子 Skill；這和 model-harness-fit 相連，因為同一份 SOP 在不同工具、模型與平台仍要重測觸發、例外與輸出行為。

這篇訪談也補強 Skill 的安全邊界：跨產品格式可攜不代表執行結果一致，第三方 Skill 可能攜帶 Python／Shell 等程式，需先盤點檔案、資料流與權限，再在最小權限環境試跑；機密資料不應因被寫進 Skill 就跳過原有治理。這把既有的 agent-sandbox-architecture 與 task-level eval gate 接到非工程師的 skill 化流程，但產品支援與格式說明仍是 BusinessNext／官方文件 attribution，不是跨產品成功率 benchmark。

修訂版：格式可攜不等於行為相容

BusinessNext 2026-08-14 的同一篇 91857 修訂版把重點收斂到跨產品移植與第三方安全：SKILL.md、references、templates 與 scripts 可以組成可搬移的 SOP 資料夾，但不同工具的安裝位置、模型對觸發條件與例外的理解仍可能不同。穩定流程要記錄搭配的工具、模型與測試案例，模型或服務更新後重新跑一次；這是 model-harness-fit 在 Skill 層的具體化，而不是把開放格式當成跨產品行為保證。

修訂版也把第三方 Skill 明確視為不受信任的外部文字與程式碼：優先使用官方版本，先列出檔案並檢查 Python／Shell 的資料讀取、權限與外連行為，再在最小權限環境試跑；AI 協助檢查只能當第一道篩選，不能取代具經驗者的資安複查。這延伸 agent-sandbox-architecture 的隔離與憑證邊界，也提醒 agent-instruction-files：機密資料不應因被寫進 Skill 就跳過原有治理。

BusinessNext 對凱鈿 HR Agent 的案例補上採用層：不要假設所有員工都會寫 prompt，而是把參照文件、動作型 Skill 與共用 Skill Library 分層，再以熟悉的網站按鈕交付。這和 agent-ready-data-governance 相連：資料要先能被 agent 引用，流程再被拆成明確觸發條件、輸入、處理與產出；RD 統一更新 Skill，避免部門各自分叉。

招募自動化的漸進採用

2026-08-27 的凱鈿招募案例補上 Skill 上線後的 adoption gate：自動化的前提是標準化，但工程師、設計師等職缺的面試資料與流程變體會讓單一腳本失效；若新系統把資深同事原本熟悉的 SOP 打散，強迫每個節點都用反而會降低採用。較穩的做法是先讓每個人只在有幫助的節點呼叫系統，讓新舊流程並行，再依團隊回饋修正。這把 Skill 從「流程檔案」擴充成 agent-experience、loop-engineering 與人類採用共同驗收的 artifact。

案例也示範角色分工的邊界：AI 可接手履歷初審、寄信、排面試與提醒等低判斷力步驟；人類保留候選人關係、適配判斷與薪資協商。Skill 的成功不應只看自動化節點數，而要看是否降低整體流程摩擦、保留必要的人類判斷，並以重複頻率與省時效益對照維護成本。

ChatGPT Work：Skill 的執行範圍取決於入口

BusinessNext 2026-08-14 的 ChatGPT Work 實測把 Skill 的 portability 邊界放進產品入口：Codex 本機資料夾的 standalone skills 供桌面 app、Codex CLI 與 IDE 擴充使用；包在 plugin 裡的 skills，則可在網頁、桌面與行動版的 Chat／Work 使用。這表示同名或同格式的 SKILL.md 不只要驗證模型行為，也要記錄它掛在哪個 runtime、能讀哪些檔案、能否跨裝置接續，以及排程由 cloud 還是 local 執行。

可重用的最小 gate 是：先選入口與執行環境 → 盤點 Skill／plugin 的檔案與權限 → 用低風險案例試跑 → 核對工具、產物與停止條件 → 再擴大授權。文章提到信箱、Notion 與外部發文仍可能不穩定，因此不能把「可載入」誤當成「可安全自治」；這需要回接 model-harness-fit、agent-sandbox-architecture、agent-experience 與 task-level eval。

產品內建 Skills 的可攜與安全 gate

BusinessNext 2026-07-20 對 Claude 方案的整理指出，Skills 可跨 Free、Pro、Max、Team 與 Enterprise 使用，但前提是開啟程式執行與檔案建立；Team／Enterprise 另可在組織內分享或集中配置。這讓 Skill 的「能不能載入」與「誰能管理」成為方案權限的一部分，而不是單純的 prompt 檔案格式。

同一篇報導也提醒，Skill 可能攜帶外部套件、程式碼或連線指示，因此啟用前要檢查來源、權限與資料流，並把高風險執行放進 agent-sandbox-architecture 的隔離與核准 gate。可攜的 SKILL.md 仍要依 agent-instruction-files、model-harness-fit 與實際工具環境重測，不能把跨產品格式當成跨產品行為相容。

從 Claude 使用情境目錄看 Skill 的邊界

BusinessNext 2026-07-21 整理 Anthropic 的 90 個 Claude 使用情境，將 Skill 放在兩種可重複能力上：把品牌規範封裝成視覺輸出規則，以及把設計原則封裝成可持續套用的工作方法。這補強了既有判準：Skill 不是「多一段提示詞」，而是把穩定的規則、參考資料與輸出要求放到可載入的能力單位，讓同一套 workflow 跨任務重用。

同一篇文章將 Skill 和其他 harness 元件分開：跨應用程式的資料與動作由 Cowork／Connectors 處理，瀏覽器內操作由 Browser Use 處理，專案背景與審查標準可放在 Projects；Skills 則承載領域規則與可重複步驟。這是產品使用情境的能力分工，不是成功率或安全性 benchmark；高風險工作仍需 agent-ready-data-governance、agent-experience 與人工核准 gate。

Routine：從示範觀察到可重跑流程

Grok Bot 的產品案例提供一個 demonstration-to-routine 變體：使用者請 Bot「下次做這件事時跟著看」，系統把觀察到的步驟保存成 routine，之後由專責 Bot 重複執行。它把 agent-skills 的「從真實任務萃取可重用能力」接到 dynamic-agent-workflows 的動態分派，但 routine 不能只因能重播就視為可靠 Skill；仍需檢查輸入變體、登入／權限狀態、失敗分支、不可逆動作與 task-level eval。

從示範錄製成 Skill

BusinessNext 2026-07-22 對 Claude Cowork「Record a skill」的整理，補上一條比手寫 prompt 更低門檻的 skill 萃取路徑：使用者在桌面版啟動錄製，一邊操作螢幕、一邊口述步驟，系統再把畫面、點擊、鍵盤輸入與說明整理成可重複呼叫的結構化 Skill。這和既有 Codex Record & Replay 同屬 demonstration-to-skill pattern，但功能細節與付費可用範圍是產品報導／官方說明，不能直接推論成功率或跨產品可攜性。

示範錄製降低了非工程師把 SOP 外化的成本，卻不會消除治理工作：錄製後仍要檢查敏感資料、權限、不可逆動作、環境依賴與失敗分支，並在不同案例上跑任務級 eval。可重用的最小流程仍是「示範一次 → 產生 Skill → 在變體案例驗證 → 把例外與 gate 寫回」，而不是把螢幕錄影直接當成可安全重播的自動化。

Teach a task：從示範到可重跑 routine

BusinessNext 的 Grok Bot 教學提供一個 demonstration-to-routine 變體：使用者在雲端電腦上示範穩定流程，系統把步驟保存成可重複執行的 routine，再用時間或事件觸發背景工作。這延伸既有「先手動跑一次 → 萃取 Skill → 在變體案例驗證」的最小流程，但也提醒 routine 不是安全隔離或成功保證；仍要檢查登入狀態、輸入變體、失敗分支、不可逆動作與人工核准。

可重用的採用 gate 是先挑每週重複、低風險且有明確輸出的工作，將職責、格式與禁止事項寫進角色／Skill，再以低權限帳號試跑並保留 artifact 與 trace；對外發送、付款、法律／合約與財務寫入不因 routine 化而自動放行，需接回 agent-sandbox-architecture、agent-experience 與 agent-trace-observability。

金融 Agent 範本：把領域流程封裝成可治理元件

BusinessNext 2026-07-24 整理 Anthropic 的金融服務範本，提供 Pitch、Meeting Prep、Market Research、Earnings Review、Model Builder、對帳、月結、報表稽核與 KYC 等 10 種工作流。這個案例把 Agent Skills 的分工具體化：Agent 負責一整條任務流程，Skill 承載分析方法與作業步驟，Connector 在權限控管下接入市場或企業資料，另外用 Commands 與 managed-agent wrappers 支援主動呼叫與後台部署。核心 financial-analysis 模組先提供共用技能與連接器，垂直 Agent 再疊上金融任務邏輯，避免每個工作流各自重造底層能力。

可重用的客製化路徑是：先替換 .mcp.json 的資料連接器，再把團隊術語、分析流程與格式規範寫進 Skill，接著調整 Agent 權限與品牌範本，最後才複製架構擴充新工作流。這使金融範本成為 agent-ready-data-governance 的一個實例：資料管道、權限、流程規則與輸出格式要一起治理，而不是只把一段 prompt 交給模型。

安全邊界不能被「可安裝」掩蓋：報導明確把產出定位為待審初稿，Agent 不執行交易、過帳或終端決策；子代理能力仍屬研究預覽，外部資料供應商則需要企業自己的訂閱與 API 金鑰。這和 agent-sandbox-architecture、model-harness-fit 及 agentic-ai-cost-management 相連：Skill 化降低重複工作的門檻，但不會消除人工核准、執行隔離與連接器成本。

Skill 的粒度：封裝任務，不是複製工具

AIHAO 2026-07-25 的 Agent Harness 導讀把 skill 的粒度連到 function-call 的 Decision 層：若把 20 個原子操作逐一暴露給模型，模型每一步都要在不自然的操作清單中重新選擇；把一類典型任務包成 skill，則能讓判斷貼近使用者任務，並由 skill 內部協調多個工具。可重用 script 也把現場生成程式的隨機性，換成已驗證參數、錯誤處理與輸出訊號。

同一篇文章將 progressive disclosure 視為 context engineering：L1 只常駐 skill name / description，L2 載入被選中的 SKILL.md，L3 再由模型按需讀取 references 與 scripts。這和既有的「skill 是 feedforward、eval 與 sensors 才是 feedback」分工一致；skill 的價值應由任務級成功率、成本與可維護性驗證，而不是由檔案數量或工具一對一包裝推定。

Skill 的可預測性與最小化

AIHAO 2026-07-25 整理 Matt Pocock 的設計哲學，將 Skill 的目的定義成「從隨機系統逼出可預測流程」：重點是每次走同樣的步驟，不是每次得到相同答案。可重用判準是把 Skill 當成工程 artifact，而不是一段越長越好的 prompt：先決定它是 user-invoked 還是 model-invoked，前者把 context load 換成人的 cognitive load，後者則要用短而精確的 description 控制觸發成本。

實作上可用四個檢查點：

• Trigger：只在需要模型自動發現時保留 description；user-invoked skill 多到難以記憶，再用 router 導航。
• Structure：把 steps 與 references 分開；是否 lazy-load 不看總長度，而看內容是否只屬於某一條 branch。
• Steering：用模型已有先驗的 leading word（例如 vertical slice），搭配清楚的 completion criterion；先修完成標準，真的觀察到 premature completion 才拆 skill。
• Pruning：逐句做 no-op test；刪除不改變行為的句子，並清掉 duplication、sediment 與 sprawl。這與 agent-instruction-files 的「只寫 agent 推不出的資訊」及 harness-engineering-for-ai-coding 的 guides / sensors 分工一致。

這個來源也補強了 loop-engineering 的 skill 化邊界：user-invoked 負責編排，model-invoked 負責可重複的紀律；skill 不能取代 tests、trace 或 task-level eval，是否真的改善行為仍要用執行 evidence 驗證。

決策先於執行：grill-me 與五站工作流

BusinessNext 2026-07-29 拆解 Matt Pocock 的 skills 專案，將 grill-me 描述成一個在動工前沿決策樹逐支追問的 Skill：一次只問一題，事實先查、決策交人拍板，每題附建議答案，所有分支達成共識前不執行。它把 context-engineering 的低認知負荷輸入、agent-instruction-files 的常駐邊界與人類 agency gate 接到同一個前置階段。

同一套工作流再把共識寫成不綁死實作細節的規格，依 vertical slice 拆成可獨立驗收的 tickets，先用 TDD 鎖定測試，再以分離的規範審查與規格忠實度審查收尾；Wayfinder 則把大型工作拆成 research、grilling、prototype、task 子票，讓每輪只吃一張新 context。這些是可重用的 workflow pattern，不是 Matt Pocock 專案成功率或效能 benchmark；落地仍需接回 loop-engineering、harness-engineering-for-ai-coding 與任務級 eval。

Gemini Spark：技能是背景任務的能力契約

BusinessNext 對 Gemini Spark 的整理把 Skill 放進一個更完整的 agent 契約：任務定義目標，排程定義何時觸發，技能定義要用哪些工具與步驟。這比把 Skill 當成單次 prompt 更接近可運轉的工作流；技能必須和資料連接器、權限範圍、進度回報及人類接手條件一起設計。

可重用的判準仍是：先確認技能需要讀寫哪些資料，再在變體案例上檢查是否能停止、回報與交還控制權。Spark 的產品功能與第三方應用清單是來源整理，不代表跨產品可攜性或成功率；要把相同模式搬進其他 harness，仍須依 model-harness-fit、agent-ready-data-governance 與 task-level eval 重測。

Gemini Spark 實測：Skill 需要和資料與排程一起驗收

BusinessNext 2026-08-05 的 Gemini Spark 實測把 Skill 放進完整的個人 agent 工作流：任務負責描述目標，排程負責觸發，Skill 負責固定的寫作風格、格式與處理步驟，Connected Apps 則提供 Gmail、Docs、Drive、Calendar 等資料與動作入口。三個實測顯示，Skill 的價值不在於能否產生漂亮文字，而在於能否對既有文件做可檢查的修改，並把重複的電子報判斷流程轉成可排程的輸出。

可重用的最小 gate 是先確認資料範圍與權限，再在低風險、可還原的任務上檢查輸出格式、停止條件、排程與人工接手；這些媒體實測不是跨產品的成功率 benchmark。若 Skill 只是把資料連接器與長 prompt 綁在一起，仍要依 model-harness-fit、agent-ready-data-governance 與 task-level eval 重測。

Cowork：Skill 之外的任務交付層

BusinessNext 2026-07-30 對 Claude Cowork 的五種場景整理，補上一個重要邊界：資料夾整理、PDF 綜合、簡報產出、CSV 視覺化與收據轉 Excel 是完整任務，不等於五個應直接抽出的 Skill。較穩的拆法是先把任務的資料範圍、輸出格式、權限與檢查點跑通；只有反覆出現的步驟，才萃取成可重用 Skill，再用不同檔案與例外案例驗證。

這也把 demonstration-to-skill 和 artifact delivery 分開：Skill 描述可重複的方法，Cowork 的本機工作台負責在授權範圍內執行並留下檔案成果。可重用的最小 gate 是「窄資料夾權限 → 計畫審查 → 執行 → 產物檢查 → 再決定是否 skill 化」，而不是因為產品能做一次就建立新的自動化抽象。

i-have-adhd：收斂式回應契約

BusinessNext 2026-08-03 整理 GitHub 開源的 i-have-adhd skill，將「怎麼回話」也納入 Skill 的能力契約：第一行先說要做什麼，省略不必要背景與岔題；每個步驟回報預估時間與已完成事項；遇到問題時直接列出問題、原因與解法。這不是把 ADHD 標籤當成診斷或臨床依據，而是從來源提取一個可跨使用者重用的低認知負荷回應格式。

可重用的邊界是把它當成任務收斂模式而不是全域人格設定：規劃、待辦與執行推進適合明確的下一步與狀態回報；腦力激盪則需要保留選項與發散空間。使用者應能明確啟用、暫停或切換模式，並保留 agent-experience 的可見狀態、ai-cognitive-offloading-and-agency 的人類目標與判斷權，以及 prompt-debugging-eval-checklist 的輸出契約驗收。

第三方 Skill 的安裝前安全檢查

BusinessNext 2026-08-04 轉述一套 GitHub Skill 安裝前檢查法：不能只對模型說「別回傳資料」，而應把第三方 Skill 當成不受信任的外部文字與程式碼，檢查整個 Skill 資料夾及其 scripts/、references/ 是否出現 HTTP、webhook、curl、fetch、requests、upload、send 等連線或外傳訊號，列出實際網址、傳送欄位與要求權限。若發現 telemetry 或 webhook 設定，應移除／停用具體設定，再執行任務；自然語言禁止本身不是可靠的資料外傳控制。

最小安全 gate 可寫成：read-only static inspection → enumerate network / permissions → remove or disable telemetry → run in least-privilege sandbox → verify outbound behavior。本地 agent 若能讀取整台電腦並執行 terminal，風險面比無外接工具的網頁聊天更大，因此要把這套檢查接到 agent-sandbox-architecture、agent-instruction-files 與 ai-native-enterprise-governance 的權限、資料流與 owner 邊界；但來源是實務提醒，不等於完整 sandbox 或網路安全保證，也不能把關鍵字命中直接視為惡意。

Wayfinder：以決策地圖處理模糊的大型工作

BusinessNext 2026-08-05 整理 Matt Pocock 的 /wayfinder，補上既有 grill-me／規格／ticket 工作流的決策前置層：先命名 destination，再把尚未能決定的問題外部化成 fog of war，只讓未被阻塞且尚未認領的 frontier ticket 前進。地圖是索引，決策留在子票；research 可交給 sub-agent 平行查證，grilling 與 prototype 則保留真人參與，避免 agent 在錯誤假設上直接產生大量交付物。

可重用的最小流程是 map → resolve one decision → update evidence → /to-spec → /to-tickets。這把 loop-engineering 的持續推進接到 harness-engineering-for-ai-coding 的停止條件與 evidence gate，也提醒 agent-instruction-files：規劃規則應只保留模型推不出的邊界，不能用更長的指令檔掩蓋尚未解決的決策。Wayfinder 可跨工程、課程與實體建造使用，但一場對話已能規劃清楚的工作不值得新增地圖層。

Capability：把工具、context 與行為設定綁成可掛載模組

Hex 的資料 agent 把 Notebook Agent、Threads 與語意模型 agent 的共通能力拆成 capability：每個模組包含工具、靜態 context、prompt 片段與難以調整的行為設定，再由不同入口掛上不同組合。這比在每個 agent 內重寫一份能力更容易維護，也讓 Skill／guide 的 progressive disclosure 有清楚的掛載位置；但 capability 收斂不等於產品入口、權限與 UI 可以直接合併，仍要用任務級 eval 驗證跨入口行為是否一致。

GitHub 資源探索：先學會選 repo，再決定是否 skill 化

BusinessNext 2026-08-06 的 GitHub 入門文補上一個 adoption gate：使用者先理解 repo、README、star、release、fork 與 clone／下載，再按「網頁直接用 → 一鍵安裝 → 自架環境」分層採用開源工具。這不是把 GitHub 當成單純的下載站，而是把 repo literacy 視為 agent-experience 的前置能力：使用者要能讀懂 AI 提問、辨認 commit／push／branch／PR／pull 的狀態差異，才有辦法和 coding agent 共用版本控制語境。

文章建議用 star 數量級、最近更新時間與是否有網頁版／一鍵安裝作為初步訊號，但也明確提醒 star 不等於品質或安全驗證。對 Skill 和開源工具，最小檢查仍是讀 README、看 issues、確認權限／API key／伺服器與 GPU 成本，並把高風險執行接回 agent-sandbox-architecture、agent-instruction-files 與 model-harness-fit；這延伸了既有的第三方 Skill 安全 gate，而不是用人氣指標取代靜態檢查。軟體免費也不等於使用免費，重要工作流程還要考慮維護與斷更風險。

可重用的最小流程是：先用低門檻資源驗證需求 → 讀 README 與維護訊號 → 檢查權限、依賴與資料流 → 在可還原案例上試跑 → 只有重複且有驗收條件的步驟才 skill 化。這和 agent-skills 的任務級 eval、loop-engineering 的 workflow 外化與 ponytail-loop-review-gate 的「先證明需要，再增加抽象」一致；來源中的專案星數、狀態與安裝方式屬 2026 年 8 月初的時點資訊，不是跨產品 benchmark。

相關頁面

• agent-instruction-files — 常駐專案背景與硬邊界
• skills-vs-mcp — skills 與 MCP 的工具設計邊界
• knowledge-to-skill-framework — 專家知識萃取成 skill 的六條路線
• harness-engineering-for-ai-coding — skill 屬於 guides；驗證仍靠 sensors
• loop-engineering — 重複 skill 可被包進外層 loop
• ai-collaboration-compounding-workflow — workflow 與偏好逐步沉澱成可重用資產
• aihao-blog — 來源媒體與知識萃取方法整理