Addy Osmani 於 2026 年 2 月開源的 agent-skills，把資深工程師的開發流程寫成 25 個技能檔，GitHub 累積 111,349 顆星標與 11,643 個分支，採 MIT 授權。專案以九個斜線指令串起規格、計畫、建置、測試、審查與上線六個階段，可安裝到七十多種 AI 編碼代理。
Agent Skills 是什麼？
Agent Skills 是一套給 AI 編碼代理使用的工程流程技能包，把規格撰寫、任務拆解、測試驅動、品質審查與上線檢查寫成可執行步驟，安裝後由代理按情境自動載入。
專案的定位寫得很直接：技能編碼的是資深工程師在建構軟體時使用的流程、品質關卡與最佳實務，並且經過封裝，讓代理在開發的每個階段都能一致遵循。
這一點與市面上多數提示詞集合不同。提示詞集合提供的是語句樣板，代理照抄即可；技能提供的是帶有進入條件、檢查點與退出條件的流程，代理必須逐步完成才能繼續。
專案建立於 2026 年 2 月 15 日，主要語言標示為 JavaScript，但實際內容以 Markdown 撰寫。倉庫同時包含 25 個技能、9 個斜線指令、4 個審查人格與 7 份共用檢查清單，最新提交時間為 2026 年 10 月 13 日。
Addy Osmani 為何要為代理寫工程技能？
因為代理預設走最短捷徑，經常跳過規格、測試與安全審查。技能把判斷寫成強制流程，讓代理在每個階段留下可驗證的證據，而非憑感覺宣稱完成。
作者在 README 的說法值得完整引用：編碼代理預設會選擇最短路徑，而最短路徑往往意味著跳過規格、測試、安全審查，以及那些讓軟體可靠的實務做法。
技能包的目標就是補上這段落差。每個技能都內含一張「反合理化」表，列出代理常用的推託說法，例如「測試稍後補上」，並附上對應的反駁。這種設計針對的是模型在時間壓力下自我放寬標準的行為模式。
內容也明顯帶著 Google 工程文化的痕跡。README 明言技能吸納了《Software Engineering at Google》的概念與 Google 的工程實務指南，具體落地為 API 設計章節的海勒姆定律、測試章節的碧昂絲規則與測試金字塔、程式審查章節的變更規模與審查時效，以及簡化章節的切斯特頓圍欄。
這套技能包包含哪些內容？
包含 25 個技能、9 個斜線指令、4 個審查人格與 7 份檢查清單。技能覆蓋規格、計畫、建置、驗證、審查與上線六個階段，另有元技能負責判斷當前工作該用哪一個。
九個斜線指令是入口，各自對應開發生命週期的一段。規格階段用 /spec，計畫階段用 /plan，建置用 /build，驗證用 /test，審查用 /review，上線用 /ship。另有 /constraints 負責一次寫定品質門檻、/webperf 做網頁效能稽核、/code-simplify 處理可讀性。
技能層的設計比指令更值得注意。規格類有訪談技能，以一次一問的方式逼出使用者真正想要的功能，直到約九成五的掌握度才停止；也有質疑驅動技能，對每個非瑣碎決定做對抗式的新脈絡審查，流程寫成主張、抽取、質疑、調和、停止五步。
驗證與交付層則偏向證據要求。測試驅動技能強制紅綠重構循環，並規定測試金字塔比例為八成單元、一成五整合、百分之五端到端；交付技能處理功能旗標、分批上線與回滾程序；可觀測性技能要求在建置當下就補上結構化日誌、紅色指標與分散式追蹤。
三種技能框架有何差異？
Superpowers 偏向方法論與協作節奏，Matt Pocock 版本偏向個人實務筆記，agent-skills 以完整生命週期與強制驗證為核心。
專案自己附了一份比較文件，把 agent-skills 與 Superpowers、Matt Pocock 的 skills 並列對照，並坦承三者形狀不同，適用場景也不同。
差異主要落在覆蓋範圍與介入時機。agent-skills 從需求訪談一路覆蓋到上線監控，優點是交接完整；Superpowers 較著重方法論框架與協作節奏，Matt Pocock 版本則更像工程師個人工作目錄的公開版，顆粒度較細但缺乏統一入口。
三者都選擇以 Markdown 作為載體，這點反映的是生態共識而非巧合。技能規格已由多家工具共同支援，純文字檔可被 Claude Code、Cursor、Codex、Copilot 等不同代理直接讀取，不需要為每個工具重寫一份。
安裝與上手方式是什麼？
最快路徑是執行 npx skills add addyosmani/agent-skills，一次安裝全部技能。Claude Code 可改用外掛市集安裝。
通用的安裝路徑是開源的 skills 命令列工具，官方稱可裝進七十多種代理。單獨安裝某個技能時要留意一個已知缺口：逐個安裝只會複製該技能目錄，倉庫層級的共用檢查清單不會跟著過去，路徑參照因此失效。
Claude Code 使用者可透過外掛市集加入倉庫並安裝外掛，指令名稱衝突時改用命名空間形式，例如審查指令要寫成帶前綴的版本。Cursor、Windsurf、OpenCode、Kiro、Gemini CLI、Codex、Copilot 與 Antigravity CLI 各有原生擺放慣例，官方為每一種都寫了獨立的設定文件。
導入節奏上，官方建議分兩條路徑。全新專案可從第一天就走完整生命週期；既有專案則採漸進方式，先從驗證相關技能開始，確認代理產出的證據可信，再逐段擴大範圍。
這些技能解決了哪些代理的通病？
主要針對三種行為：跳過規格直接寫程式、以自行修改測試換取通過、以及憑感覺宣稱完成。技能以驗證條件與反合理化表逐項封堵，要求代理交出可檢查的證據。
第一種通病是省去定義階段。代理擅長在模糊需求下立刻產出程式碼，看起來效率極高，但方向錯誤時返工成本最高。訪談技能與規格技能把這段前置工作變成必經關卡，並且要求寫成文件。
第二種通病是為了讓測試通過而改測試。品質門檻技能明確把這種行為列為偵測目標，要求檢查項目按成本分層擺放，並在代理關閉檢查或跳過測試時觸發警示。
第三種通病是宣稱完成卻無證據。幾乎每個技能都以證據要求收尾：測試通過的輸出、建置結果、執行時資料，README 直言「看起來正確」永遠不足夠。這條規則看似嚴苛，實際上是把驗證成本從除錯階段往前移到建置階段。
有哪些限制與風險？
限制包括逐個安裝時的檢查清單遺失、部分指令僅限特定工具、以及技能本身無法保證代理遵守。專案現有 180 個待處理議題，行為仍隨版本變動。
第一項是工具落差。九個生命週期指令屬 Claude Code 的外掛指令，在 Copilot 等環境不會出現，使用者必須改為直接呼叫技能名稱。這種差異在跨工具團隊中容易造成混亂。
第二項是技能與執行力的距離。技能是寫給代理讀的流程文件，代理是否遵循取決於模型能力與當次脈絡。文件寫得再嚴謹，也無法強制一個急於交付的模型停下來寫規格。
第三項是規模與治理。倉庫現有 180 個待處理議題、549 名關注者，維護者為 Addy Osmani 與兩位協作者。專案採 MIT 授權，商業使用無授權障礙，但技能內容帶有明顯的個人工程觀點，團隊導入時仍須按自身技術棧調整。
出處連結有哪些？
主要來源為 GitHub 倉庫 addyosmani/agent-skills，技能清單與指令說明取自官方 README，比較與導入建議見倉庫文件目錄下的對照文件。
倉庫網址為 https://github.com/addyosmani/agent-skills，README 載明六階段流程圖、九個指令對照表、25 個技能清單、4 個審查人格與 7 份檢查清單，並附各工具的設定文件索引。
專案亦公開比較文件與一份由第三方完成的對照實驗連結，供團隊在選型時參考。技能格式規格另見倉庫文件目錄下的技能解剖說明。
總結：Agent Skills 適合什麼團隊？
適合已在多種代理之間切換、需要一致工程紀律的團隊。若只是偶爾用代理寫小工具，完整流程反而是負擔；技能價值在於長期專案的品質穩定性。
這套技能包的真正賣點是把工程判斷外化。當團隊同時使用 Claude Code、Cursor 與 Codex，每種工具的預設行為都不同，把紀律寫成共用的 Markdown 檔案，是現階段少數可行的統一方式。
限制同樣清楚。它不提供模型、不代管程式碼、也不替代團隊自己的審查文化。技能是流程載體，遵循與否仍取決於使用者的要求強度。
對正在評估代理工作流的團隊，最實際的做法是先安裝規格與測試兩組技能，在一個小型功能上試跑一輪，觀察代理交出的證據是否足以取代原本的人工檢查，再決定是否擴大覆蓋範圍。
