by Rain Chu 6 月 18, 2026 | AI , skills
前言：AI 編碼不是「一句 Prompt 就完成」
用 Claude Code、Codex、Cursor、Gemini CLI 或其他 AI Coding Agent 來開發
一開始看起來很神奇：
但實際進入專案後，問題也很快浮現：
AI 寫出來的程式碼不一定符合需求。
這正是 Matt Pocock 開源 skills 專案想解決的問題。
Matt Pocock 在官方 GitHub 專案中寫下這句話：
Skills for Real Engineers. Straight from my .claude directory.
這句話很關鍵。
它不是在說「給 AI 更多 Prompt」。
什麼是 Matt Pocock Skills？
Matt Pocock 的 skills 是一組為 AI Coding Agent 設計的工作流指令集。
它可以安裝到支援 Skill 機制的 AI 編碼工具中，例如 Claude Code 或其他類似 Agent 工具，讓 AI 在不同任務中使用特定工作流。
官方快速安裝方式如下：
npx skills@latest add mattpocock/skills 安裝後，使用者可以選擇需要的 Skills，並在 Agent 中執行：
/setup-matt-pocock-skills 這個設定流程會詢問：
你使用哪一種 Issue Tracker，例如 GitHub、Linear 或本地檔案
你的需求或任務如何標籤化
文件與決策紀錄要存放在哪裡
Agent 之後要如何理解你的專案上下文
也就是說，這套工具不是讓 AI 直接「衝去寫程式」，而是先建立專案語言、工作流與交付紀律。
核心概念：不要 Vibe Coding，要工程化 AI Coding
很多人使用 AI 寫程式時，採用的是 Vibe Coding 模式。
所謂 Vibe Coding，大概就是：
我有一個想法 → 丟給 AI → 讓 AI 自己改 → 看起來可以就合併 這種方式在 Demo、原型、小工具上很快。
但放到真實產品，就容易遇到幾個問題：
需求沒有講清楚，AI 直接做錯方向
程式碼越改越亂，沒有人負責架構
沒有測試，AI 不知道自己是否改壞東西
對話太長，Agent 開始忘記前面的脈絡
任務太大，AI 一次修改太多地方
Review 負擔轉移給人類，結果工程師更累
Matt Pocock 的 Skills 工作流，本質上是在提醒開發者：
AI 編碼痛點一：Agent 沒有真正理解需求
問題
AI Coding 最常見的失敗，不是語法錯誤，而是「它做的不是你要的」。
你可能請 AI 做一個後台報表頁面。
但等你看完結果才發現：
欄位不是老師真正需要看的欄位
查詢條件不符合業務流程
權限設計漏掉角色差異
空狀態、錯誤狀態、邊界案例沒有處理
它理解的「報表」跟你理解的完全不同
這不是 AI 不聰明，而是需求沒有對齊。
對應 Skill：/grill-me 與 /grill-with-docs
Matt Pocock 的解法是：
/grill-me 的精神是讓 Agent 不急著產出方案，而是先進行一輪深入訪談。
/grill-with-docs 則更進一步。
專案上下文
領域用語
架構決策紀錄
需求背後的取捨
模組與資料流說明
這讓 AI 不是只靠當前聊天室的上下文做判斷，而是能逐步累積專案知識。
實務建議
在真實專案中，不要一開始就叫 AI：
更好的做法是先執行需求釐清：
然後讓 AI 問你：
主要使用者是誰？
他最想完成什麼？
哪些步驟不能捲動？
成功送出前需要哪些驗證？
什麼情況下不能開始批改？
結果要如何呈現？
這個頁面未來會不會支援批次上傳？
等這些問題釐清後，再讓 AI 產出 PRD、Issue 或程式碼。
這樣做看起來比較慢，但通常可以避免後面大規模重工。
AI 編碼痛點二：Agent 太囉嗦，專案語言不一致
問題
AI 很常「講得很多，但不精準」。
在一個真實產品中，團隊內部通常會有自己的領域語言。
模板
答案卷
評分規準
批改結果
班級
學生作業
題目配分
AI 批改任務
如果 AI 沒有掌握這些詞，它就會用很長的描述代替一個簡短的專案術語。
長期下來會造成幾個問題：
變數命名不一致
文件描述不一致
Agent 每次都重新解釋一次
Token 消耗增加
新功能接不上既有架構
不同 Session 產出的程式碼風格不一致
對應 Skill：共享語言與 CONTEXT.md
Matt Pocock 的 Skills 強調建立 Shared Language，也就是共享語言。
共享語言的概念很接近領域驅動設計，也就是讓工程師、產品人員、領域專家與 AI Agent 使用同一套詞彙。
在 Skills 工作流中，這些資訊可以被整理進 CONTEXT.md 或 ADR 文件中。
例如原本 AI 可能會寫：
當老師上傳某個學生的作業圖片後，系統會根據題目和答案資訊產生評分結果。 但如果專案已經定義好術語，它就可以更精準地寫成：
Grade Job 會根據 Submission 與 Answer Key 產生 Grading Result。 這樣不只是文字變短，而是整個專案開始有穩定的語言系統。
實務建議
導入 Skills 時，建議先建立一份 CONTEXT.md，內容包含：
# Project Context
## Domain Terms
- Submission：學生上傳的單份作業
- Template：批改模板，包含題目結構與答案格式
- Answer Key：標準答案與配分
- Grade Job：一次 AI 批改任務
- Grading Result：批改完成後產生的分數、評語與錯誤分析
## Product Principles
- 教師應能在不捲動頁面的情況下完成單份作業批改
- 主按鈕只用於最重要的批改行為
- 介面應避免學生向玩具風，保持教師專業感 這份文件不是給人看的而已，也是給 AI Agent 看的。
當 AI 有了穩定的詞彙，它就比較不容易每次都重新發明一套命名方式。
AI 編碼痛點三：程式碼看起來對，但實際不能用
問題
AI 產生的程式碼常常有一種錯覺：
常見情況包括：
TypeScript 型別通不過
API 欄位名稱對不上
資料庫 Schema 沒同步
測試沒有涵蓋邊界情境
UI 看似完成，但實際操作失敗
修一個 Bug 又打壞另一個功能
這是因為 AI 如果沒有回饋迴路，就像閉著眼睛寫程式。
它需要知道：
型別檢查是否通過
測試是否通過
瀏覽器畫面是否正常
CLI 指令是否成功
錯誤訊息是什麼
哪個 Commit 造成回歸
對應 Skill：/tdd 與 /diagnosing-bugs
Matt Pocock 的解法是把測試與診斷流程變成 Skill。
/tdd 強調 Red-Green-Refactor：
Red：先寫一個失敗的測試
Green：寫最小程式碼讓測試通過
Refactor：在測試保護下重構
這讓 AI 不只是「寫出看起來合理的程式碼」，而是用測試證明功能真的成立。
/diagnosing-bugs 則適合處理 Bug。
重現錯誤
最小化案例
提出假設
加入觀測與紀錄
修正問題
補上回歸測試
這比直接叫 AI「幫我修掉」穩定很多。
實務建議
當你要讓 AI 修改功能時，可以這樣要求：
使用 /tdd 幫我完成這個功能。
請先寫 failing test，再實作功能，最後重構。
不要一次修改太多檔案。 遇到 Bug 時可以改成：
使用 /diagnosing-bugs。
請先重現問題，不要直接猜測修法。
找到 root cause 後再提出修正方案。
最後補上 regression test。 這種方式會讓 AI 的輸出慢一點，但品質通常更好。
AI 編碼痛點四：系統越做越像一團泥球
問題
AI 最大的優點是寫得快。
如果沒有架構約束，AI 會快速產生：
過大的 Component
混亂的資料流
重複的工具函式
不一致的命名
隱性耦合
到處散落的商業邏輯
難以測試的模組
最後專案會變成 Ball of Mud，也就是一團泥球。
功能看起來都有，但每次修改都很痛苦。
對應 Skill：/improve-codebase-architecture 與 codebase-design
Matt Pocock 的 Skills 裡面不只關心「功能做出來」，也關心「系統是否還能長期演進」。
/improve-codebase-architecture 的用途是掃描程式碼庫，找出架構可以改善的地方。
哪些模組太淺
哪些抽象不夠穩定
哪些介面太大
哪些責任混在一起
哪些地方不容易測試
哪些功能應該被拆成更深的模組
codebase-design 則提供一套讓 AI 判斷模組設計的語言。
這對 AI Coding 非常重要。
實務建議
如果你的 AI Agent 已經連續幫你開發好幾天，建議定期執行：
/improve-codebase-architecture 可以設定成每幾天做一次架構健檢，尤其是在以下情境：
新功能大量加入後
多個 Agent 平行開發後
頁面開始變得難維護
測試越來越難寫
開發者開始不確定邏輯應該放哪裡
同一種資料轉換出現在很多檔案中
AI 不只應該幫你加功能，也應該幫你守住系統結構。
一張圖看懂 Matt Pocock Skills 工作流
可以把這套流程想成四個階段：
這個流程的重點不是工具本身，而是節奏。
AI 不應該一次吃下整個專案。
WordPress 技術文章可用的導入範例
如果你要把這套工作流放進 WordPress 技術團隊或個人開發流程，可以這樣設計：
1. 建立專案上下文
在專案根目錄建立：
內容包含：
專案目標
使用者角色
核心流程
領域名詞
技術堆疊
不可違反的設計原則
重要資料表
API 命名規則
UI 風格規範
2. 每個功能先做需求釐清
不要直接要求 AI 實作。
先使用：
讓 AI 問清楚需求。
3. 把需求轉成 PRD
需求清楚後，再使用：
讓 AI 產出產品需求文件。
4. 拆成 Issues
接著使用：
把 PRD 拆成可獨立完成的小任務。
每個 Issue 最好具備：
明確輸入
明確輸出
明確驗收標準
可測試範圍
不超過一個主要模組
5. 實作時使用 TDD
每個 Issue 開始實作時，使用：
讓 AI 先寫測試，再寫功能。
6. 定期做架構整理
每完成幾個 Issue，執行：
/improve-codebase-architecture 把 AI 快速產生的程式碼重新拉回可維護狀態。
什麼專案最適合使用 Matt Pocock Skills？
這套 Skills 特別適合以下情境：
你正在開發真實產品，不只是 Demo
你使用 Claude Code、Codex 或其他 Agent 工具
你希望 AI 參與需求、測試、架構與文件
你的專案有複雜商業邏輯
你需要多人協作
你不希望 AI 把程式碼改成不可維護
你希望建立可重複使用的 AI 開發流程
例如：
SaaS 後台
教育科技平台
金融分析工具
電商系統
內部管理平台
WordPress 外掛
API 服務
多 Agent 開發流程
如果只是一次性的簡單腳本，這套流程可能會顯得偏重。
常用 Skills 整理
/setup-matt-pocock-skills第一次導入時使用。
/grill-me讓 AI 針對你的想法進行深入提問。
/grill-with-docs進階版需求釐清。
/to-prd把目前對話整理成 PRD。
/to-issues把 PRD、計畫或規格拆成可執行的 Issues。
/tdd用測試驅動開發方式完成任務。
/diagnosing-bugs用紀律化方式診斷 Bug。
/improve-codebase-architecture掃描程式碼庫並提出架構改善方向。
git-guardrails-claude-code設定 Git 安全防護，避免 Agent 執行危險 Git 指令。reset --hard、clean 或不該執行的 push 行為。
為什麼這套方法值得關注？
Matt Pocock Skills 的重點，不是發明一個全新的 AI 工具。
它提醒我們：
AI 不缺寫程式碼的能力。
而這些東西，正是軟體工程的核心。
如果你只把 AI 當成程式碼產生器，它很快會帶來混亂。
AI Coding 的下一步，是工作流工程化
AI 編碼正在從「Prompt 技巧」進入「工作流設計」。
早期大家在比較誰的 Prompt 寫得好。
有沒有清楚的需求釐清流程
有沒有穩定的專案上下文
有沒有測試回饋
有沒有架構守門
有沒有 Issue 拆解
有沒有安全邊界
有沒有讓人類重新介入審查的節點
Matt Pocock 的 Skills 專案，正好提供了一個很好的起點。
它不是叫你把專案完全交給 AI。
如果你已經開始使用 Claude Code、Codex 或其他 AI Coding Agent，這套 Skills 很值得安裝到你的專案裡試試看。
官方 GitHub： https://github.com/mattpocock/skills
下載 Skills： https://github.com/mattpocock/skills/archive/refs/heads/main.zip
快速安裝： npx skills@latest add mattpocock/skills
建議第一批先選這 8 個
在安裝的畫面裡，先用空白鍵勾選這些：
setup-matt-pocock-skillsgrill-with-docsto-prdto-issuestdddiagnosing-bugsimprove-codebase-architecturecodebase-design 這 8 個是最適合「真實專案開發」的主流程。
為什麼先選這些？
1. setup-matt-pocock-skills
第一次一定要選。
2. grill-with-docs
用來讓 AI 先問清楚需求，不要一開始就亂寫 code。
3. to-prd
把討論內容整理成 PRD。
4. to-issues
把 PRD 拆成一個一個可執行的 issue。
5. tdd
用測試驅動開發方式實作。
6. diagnosing-bugs
Debug 專用。
7. improve-codebase-architecture
定期檢查專案架構。
8. codebase-design
用來建立或檢查程式碼設計原則。
第二批可以考慮加裝
等你開始穩定使用後，再加這些：
grill-metriageprototypereviewimplementgit-guardrails-claude-codesetup-pre-commitrequest-refactor-plan 用途如下：
Skill 適合情境 grill-me還沒有文件，只是想法階段，讓 AI 先問你問題 triage分析 bug、issue、需求優先級 prototype快速做原型 review請 AI 做 code review implement根據 issue 實作功能 git-guardrails-claude-code防止 Claude Code 亂下危險 git 指令 setup-pre-commit設定 pre-commit hooks request-refactor-plan先產生重構計畫，不直接動手改
其中我特別建議你後面一定要補：
git-guardrails-claude-codereviewimplementsetup-pre-commit 因為你會讓 AI 寫真實專案，Git 安全與 review 很重要。
暫時不用選的
這些可以先跳過：
ask-mattteachhandoffdomain-modelingdecision-mappingdesign-an-interfaceedit-articleobsidian-vaultscaffold-exerciseswriting-beatswriting-fragmentswriting-shape 不是不好，而是它們比較偏教學、寫作、知識整理或特殊用途。
實戰開發組合的選法
可以先這樣選：
[x] setup-matt-pocock-skills[x] grill-with-docs[x] to-prd[x] to-issues[x] tdd[x] diagnosing-bugs[x] improve-codebase-architecture[x] codebase-design[x] git-guardrails-claude-code[x] review[x] implement[x] setup-pre-commit
by Rain Chu 6 月 18, 2026 | AI , skills
如果你已經開始使用 Claude Code 寫程式，你可能很快會遇到一個問題：AI 很會寫程式碼，但不一定會像真正的工程團隊一樣工作。
真正的軟體開發，不只是「寫出功能」而已，它還包含需求判斷、產品取捨、架構審查、設計檢查、品質測試、安全稽核、文件更新、部署驗證與事後回顧。
這也是 gstack 受到開發者關注的原因。
gstack 是由 Garry Tan 開源的 Claude Code 外掛式工具組。它的核心概念很簡單：不要再把 Claude Code 當成單一聊天機器人，而是把它變成一支有分工、有角色、有流程的 AI 工程團隊。
官方 GitHub：https://github.com/garrytan/gstack
下載 ZIP：https://github.com/garrytan/gstack/archive/refs/heads/main.zip
gstack 是什麼？
gstack 可以理解成一套 Claude Code 的「專家角色技能包」。
安裝之後，你可以在 Claude Code 中使用一系列 slash command，讓 AI 以不同角色協助你完成軟體開發流程。例如：
CEO：重新檢查產品方向與市場價值
工程主管：審查架構、資料流、邊界條件與測試策略
設計師：檢查 UI/UX 品質，避免 AI 產生粗糙介面
QA：實際開啟瀏覽器測試網頁流程
資安主管：用 OWASP Top 10 與 STRIDE 角度檢查安全風險
Release Manager：協助測試、合併、部署與驗證正式環境
換句話說，gstack 不是單純幫你多加幾個提示詞，而是把 AI 寫程式這件事，從「單人問答」升級成「團隊協作流程」。
為什麼它像一支 20 人的矽谷工程團隊？
一般使用 Claude Code 時，你可能會這樣下指令：
「幫我做一個登入頁。」
Claude Code 會照做，但它不一定會主動幫你思考：
這個功能真的重要嗎？
使用者流程是否清楚？
架構是否會造成未來維護困難？
邊界條件是否處理完整？
UI 是否有 AI 生成感？
有沒有資安風險？
上線後要怎麼驗證？
gstack 的價值就在於把這些問題拆成不同角色，由不同指令分別處理。
你不再只是在叫 AI 寫程式，而是在指揮一組 AI 產品與工程團隊。
特色
1. 從提示詞升級為角色分工
gstack 最大的特色，是把 Claude Code 的能力拆成不同專家角色。你可以根據任務階段，呼叫 CEO、工程主管、設計師、QA、資安主管或發布工程師。
這讓 AI 不只是執行命令，而是從不同專業角度幫你審查決策。
2. 適合個人開發者與小團隊
對一人公司、獨立開發者、小型新創團隊來說，最缺的通常不是點子，而是完整的開發紀律。
gstack 可以補上這些角色：
產品判斷
架構審查
設計審查
程式碼審查
QA 測試
資安檢查
部署流程
文件更新
它不會真的取代 20 個人，但可以讓一個開發者在流程上更接近成熟工程團隊。
3. 專為 Claude Code 設計
gstack 是圍繞 Claude Code 的工作方式設計的。安裝後會加入 Claude Code 的 skills，讓你直接在 Claude Code 中用 slash command 操作。
例如：
/plan-ceo-review
/plan-eng-review
/review
/qa
/ship 這比每次重新寫一大段提示詞更穩定，也更容易建立固定工作流程。
4. 可以實際操作瀏覽器做 QA
gstack 的 /qa 與 /browse 類指令不是單純在腦中想像測試流程，而是能搭配瀏覽器自動化工具，實際開啟網頁、點擊、觀察畫面、檢查錯誤。
這對前端開發、後台系統、SaaS 產品特別有用。
5. 支援團隊模式
如果你不是一個人開發，而是和其他工程師共同維護 repo，gstack 也提供 Team mode。你可以把 gstack 的要求寫入專案設定，讓團隊成員在使用 Claude Code 時都採用同一套 AI 協作規範。
這對團隊一致性很重要，因為 AI 工具最怕的不是不能寫，而是每個人用法不同、品質標準不同、上下文不同。
關鍵指令
以下是實務上最值得先學的 gstack 指令。
/office-hours適合在專案早期使用。你可以用它描述你正在做的產品、功能或問題，讓 AI 協助你釐清方向。
適合情境：
新功能發想
專案方向討論
不確定下一步要做什麼
想讓 AI 先理解整體背景
/plan-ceo-review用 CEO 或創辦人的角度檢查產品方向。
它會幫你思考：
這個功能是否真的值得做？
是否能創造足夠價值？
是否有更簡單、更有效的做法？
這是不是只是在做「看起來很忙」的功能？
適合在開始寫程式前使用。
/plan-eng-review用工程主管角度檢查技術計畫。
它會關注：
架構是否合理
資料流是否清楚
邊界條件是否完整
測試策略是否足夠
是否有隱藏假設
適合在準備開發前使用，尤其是資料庫、API、權限、部署流程相關功能。
/plan-design-review用設計師角度檢查功能規劃。
它會關注：
使用者流程是否清楚
UI 是否直覺
視覺層級是否合理
是否有 AI 生成感
是否符合產品定位
如果你正在做前端頁面、後台介面、SaaS Dashboard，這個指令非常有價值。
/design-consultation適合從零開始建立設計方向。
例如你可以請它協助：
設計首頁
規劃後台介面
建立設計系統
產生多種 UI 方向
檢查競品與市場風格
/review用資深工程師角度檢查目前分支的程式碼。
它不是只看語法，而是會幫你找：
CI 可能不會抓到的正式環境 Bug
架構問題
可維護性問題
遺漏的錯誤處理
測試不足的地方
開 PR 前可以先跑一次。
/investigate除錯專用指令。
這個指令的重點是：先調查，再修復。
很多 AI 寫程式的問題，是一看到錯誤就直接亂改。/investigate 比較像真正的資深工程師，會先找根因、追資料流、確認假設，再提出修正方式。
/qa用 QA 角度測試你的應用程式。
它適合用在：
前端頁面測試
表單流程測試
登入後台測試
SaaS 使用者流程測試
修復 Bug 後的回歸測試
如果你有 staging URL，可以讓它實際操作頁面。
/qa-only和 /qa 類似，但只產出報告，不直接修改程式碼。
適合你只想知道問題在哪裡，暫時不想讓 AI 動手修。
/cso用資安主管角度做安全檢查。
它會從常見 Web 安全風險與威脅模型角度檢查問題，例如：
權限控管
資料外洩
Injection 風險
身分驗證問題
API 濫用
邊界條件
對 SaaS、會員系統、後台系統、金流系統特別重要。
/ship協助準備發布。
它通常會處理：
同步主分支
執行測試
檢查覆蓋率
推送變更
開啟 PR
適合功能完成後使用。
/land-and-deploy協助合併與部署後驗證。
它的目標不是只把程式碼合併，而是一路確認部署結果與正式環境健康狀態。
/canary適合部署後觀察。
可以用來檢查：
Console error
效能退化
頁面故障
部署後異常
/benchmark做效能基準測試。
適合比較功能修改前後：
頁面載入速度
Core Web Vitals
資源大小
前端效能變化
/document-release發布後更新文件。
它可以協助你檢查 README、使用說明、版本紀錄是否跟實際功能一致。
/retro做專案回顧。
適合每週或每個功能完成後使用，檢討：
哪裡做得好
哪裡卡住
測試健康度
發布節奏
下次如何改善
安裝方式
官方建議先準備以下工具：
Claude Code
Git
Bun v1.0+
Windows 使用者需額外準備 Node.js
Claude Code 安裝指令
在 Claude Code 中貼上以下指令：
git clone --single-branch --depth 1 https://github.com/garrytan/gstack.git ~/.claude/skills/gstack && cd ~/.claude/skills/gstack && ./setup 接著依照官方 README 的建議，在 CLAUDE.md 加入 gstack 區塊，讓 Claude Code 知道可以使用 gstack skills。
Team mode：讓整個團隊一起使用 gstack
如果你希望整個 repo 都採用 gstack，可以在專案目錄內執行：
(cd ~/.claude/skills/gstack && ./setup --team) && ~/.claude/skills/gstack/bin/gstack-team-init required && git add .claude/ CLAUDE.md && git commit -m "require gstack for AI-assisted work" 如果你不想強制團隊成員使用，可以把：
改成：
Windows 使用者注意事項
如果你在 Windows 11 上使用 gstack，官方建議透過 Git Bash 或 WSL 使用。除了 Bun 之外，也需要 Node.js。
如果你使用 Git Bash，而且沒有開啟 Windows Developer Mode，安裝方式可能會改用檔案複製而不是 symlink。這種情況下，每次 git pull 更新 gstack 後，建議重新執行：
cd ~/.claude/skills/gstack && ./setup gstack 適合誰？
1. 獨立開發者
如果你一個人同時要負責產品、設計、前端、後端、測試、部署，gstack 可以幫你補上流程與審查角色。
2. 技術創業者
如果你是創辦人，還想自己快速做 MVP、測試市場、修功能、部署產品，gstack 可以讓 Claude Code 更像一支小型產品工程團隊。
3. 小型工程團隊
如果團隊已經在使用 Claude Code，gstack 可以統一 AI 協作流程，避免每個工程師都用不同提示詞、不同品質標準。
4. 想建立 AI 開發流程的人
gstack 的價值不只在工具本身，也在於它示範了一種新的 AI 開發方法：
不是叫 AI「幫我寫程式」，而是讓 AI 依照產品、工程、設計、QA、資安、部署流程協作。
建議工作流程
如果你是第一次使用 gstack，可以先照這個流程：
先描述你要做的產品或功能。
確認這個功能是否值得做。
確認架構與資料流是否合理。
確認使用者體驗與畫面設計是否足夠好。
開發完成後做程式碼審查。
實際測試頁面與流程。
針對安全風險做檢查。
準備發布。
合併、部署並驗證正式環境。
完成後做回顧，整理下次可以改善的地方。
gstack 的真正價值：讓 AI 開發變得有紀律
很多人使用 AI 寫程式時，最大的問題不是 AI 不夠強，而是流程太鬆散。
今天叫 AI 改一點，明天叫 AI 補一點，後天再叫 AI 修 Bug。久了之後，專案很容易變成：
架構混亂
文件過期
UI 不一致
測試不足
部署流程不穩
功能越改越難維護
gstack 的出現，代表 AI 輔助開發正在從「聊天式開發」進入「流程式開發」。
它把專業團隊的工作方式拆成一個個明確指令，讓 Claude Code 不只是會寫程式，而是能依照更成熟的軟體工程流程工作。
by Rain Chu 6 月 18, 2026 | AI , skills
現在越來越多工程師會使用 Claude Code、Cursor、Codex、Gemini CLI 或其他 AI coding agent 來協助寫程式。只要輸入一句「幫我做登入功能」、「幫我修這個 bug」，AI 就能快速產生程式碼，看起來效率很高。
但真正把 AI 放進日常開發流程後，很快就會遇到幾個問題：
需求還沒釐清，AI 就開始寫程式。
這些問題通常不是模型不夠聰明，而是工作流程不夠可靠。
Superpowers 要解決的，正是這件事。
Superpowers 是什麼？
Superpowers 是目前 Claude Code 社群裡很熱門的 Skills 框架之一，專門用來強化 AI 的開發流程。它不是單純讓 AI 「更會寫程式」，而是讓 AI 在寫程式之前、寫程式之中、寫完之後，都按照一套更有紀律的流程工作。
你可以把 Superpowers 想成一套給 AI coding agent 使用的「開發工作手冊」。
它會提醒或要求 AI 在不同階段使用對應的 Skill，例如：
需求不清楚時，先進行 brainstorming。
也就是說，Superpowers 的價值不只是「增加功能」，而是讓 AI 開發變成一個可檢查、可追蹤、可驗證的流程。
為什麼需要 Superpowers？
很多人使用 AI 寫程式的方式，其實還停留在「提需求，等結果」。
例如：
幫我新增一個學生作業上傳功能。
AI 可能很快就改了一堆檔案，新增 API、修改 UI、調整資料庫欄位，看起來很有效率。但問題是：
它真的理解需求嗎？
如果這些問題沒有被處理，AI 寫得越快，後續返工可能越多。
Superpowers 的核心理念是：
聰明是模型的事，可靠是流程的事。
模型可以幫你寫程式，但流程要讓它知道什麼時候該停下來、什麼時候該問問題、什麼時候該測試、什麼時候才算真的完成。
Superpowers 的核心流程
Superpowers 的開發流程可以簡化成四個階段：
1. Design：先設計，不急著寫
當你要做新功能時，不要一開始就叫 AI 寫程式。Superpowers 會鼓勵 AI 先透過 brainstorming 釐清需求。
這個階段的重點包括：
確認真正要解決的問題
這可以避免 AI 一開始就走錯方向。
2. Plan：把任務拆成可執行步驟
需求確認後，下一步不是直接寫 code，而是建立實作計畫。
常用 Skill：
/superpowers:writing-plans 這個 Skill 會把任務拆成一個個很清楚的小步驟，包括：
要修改哪個檔案
好的計畫不是寫給「很懂專案的人」看的，而是寫給「新開的 AI session 或 junior engineer」也能照著完成的人看的。
這一點非常重要。因為 AI 很容易在長對話中忘記上下文，或在不同 session 之間失去脈絡。明確的 plan 可以降低這個問題。
3. Test：先測試，再實作
Superpowers 很重視 test-driven-development，也就是 TDD。
它希望 AI 不要直接寫功能，而是：
先寫一個會失敗的測試
這種流程看起來比較慢，但對 AI 開發非常重要。
因為 AI 最大的風險之一是「看起來完成了，但其實沒有驗證」。
TDD 可以把完成標準變成具體的測試，而不是只靠 AI 自己說「已經完成」。
4. Quality：完成之前必須驗證
AI 很常說：
功能已完成。
但實際上可能沒有跑測試、沒有 build、沒有 lint，甚至沒有啟動專案確認。
Superpowers 的 verification-before-completion 就是為了解決這個問題。
它會要求 AI 在宣稱完成之前，先執行必要驗證，例如：
npm test
npm run build
npm run lint
npm run typecheck 如果是後端專案，也可以包含：
pytest
go test ./...
cargo test 如果是前端專案，則可能需要：
npm run test
npm run build
npm run dev 重點不是指令本身，而是「不能沒有驗證就說完成」。
Superpowers 常用 Skill 整理
Skill 用途 適合情境 brainstorming 釐清需求 新功能、新模組、新流程 writing-plans 撰寫實作計畫 需求明確後，準備拆任務 test-driven-development 測試驅動開發 新功能、重構、修 bug systematic-debugging 系統化除錯 測試失敗、bug 無法定位 verification-before-completion 完成前驗證 AI 說完成之前 requesting-code-review 請 AI 做程式碼審查 功能完成後 using-git-worktrees 隔離開發環境 多任務、多分支、避免互相污染 subagent-driven-development 透過子代理執行計畫 任務可拆分、需要分工 executing-plans 依照計畫執行 想照步驟穩定完成 finishing-a-development-branch 收尾開發分支 功能完成後準備合併
關鍵指令：find skills
安裝 Superpowers 後，最重要的第一個指令是：
這個指令可以讓 AI 掃描目前可用的 Skills，幫你知道現在有哪些能力可以使用。
建議你在每次進入新專案，或剛安裝 Superpowers 後，都先輸入：
接著可以再問：
請列出目前可用的 Superpowers skills，並說明每個 skill 適合在什麼情境使用。 或是：
請根據目前這個專案，建議我應該優先使用哪些 Superpowers skills。 這樣可以避免你裝了 Skills，卻不知道什麼時候該用。
Claude Code 常用安裝方式
官方 GitHub：https://github.com/obra/superpowers
下載與安裝可以從官方 GitHub 頁面開始：https://github.com/obra/superpowers
如果你使用 Claude Code，可以透過官方 plugin marketplace 安裝：
/plugin install superpowers@claude-plugins-official 也可以加入 Superpowers marketplace：
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace 安裝完成後，建議先執行：
確認 Superpowers 是否正確載入。
建議的日常使用流程
如果你是第一次把 Superpowers 放進專案，可以先採用以下流程：
第一步：先找 Skills
請 AI 列出目前能使用的 Skills，並說明哪些適合目前專案。
第二步：新功能先 brainstorming
你可以這樣對 Claude Code 說：
我要新增一個學生作業上傳與 AI 批改功能，請使用 Superpowers 的 brainstorming 先幫我釐清需求，不要直接寫程式。 這樣可以避免 AI 直接動手，先把需求問清楚。
第三步：確認設計後寫計畫
/superpowers:writing-plans 或直接說：
請根據剛剛確認的設計，使用 writing-plans 幫我建立實作計畫。 第四步：依照計畫執行
如果任務較大，可以使用：
請使用 subagent-driven-development 依照這份 plan 執行。 如果任務比較小，也可以說：
請使用 executing-plans 逐步執行，完成每一步都回報。 第五步：完成前要求驗證
在你說完成之前，請使用 verification-before-completion，實際執行測試、build、lint，並回報結果。 這是整個流程中最重要的一步。
AI 說完成不代表真的完成。
Superpowers 適合哪些人？
Superpowers 特別適合以下情境：
長期維護的產品
如果你只是想快速做一個一次性 demo，Superpowers 可能會顯得比較重。因為它會要求你先釐清需求、寫計畫、寫測試、做驗證，流程比單純 vibe coding 更嚴謹。
但如果你的目標是打造可維護、可驗證、可交接的程式碼，Superpowers 的價值就很明顯。
Superpowers 的限制
Superpowers 不是萬靈丹。
它可以讓 AI 更有紀律，但仍然有幾個限制：
第一，它主要依靠 AI 遵守規則。
第二，它需要專案本身有良好的測試與建置指令。
第三，它會增加前期流程成本。
第四，開發者仍然要審查結果。
所以最好的使用方式不是完全放手，而是把 Superpowers 當成一套「AI 開發 SOP」。
一張圖理解 Superpowers 流程
這套流程的核心不是讓 AI 一次寫更多程式，而是讓 AI 每一步都可被確認、可被驗證、可被追蹤。
參考資源
官方 GitHub：https://github.com/obra/superpowers
by Rain Chu 6 月 18, 2026 | AI , skills
你可以把 find-skills 想成是 Agent 專用的「Skill App Store」。
當你未來想問：
「有沒有適合做 React 優化的 Skill？」
「有沒有可以幫我寫 changelog 的 Skill？」
「有沒有支援 PR Review、測試、自動化部署的 Skill？」
安裝 find-skills 之後，Agent 就可以根據你的需求，去搜尋相關 Skills，並提供安裝建議。
為什麼第一個要裝 find-skills？
一般人在剛開始使用 Agent Skills 時，最常遇到的問題不是「不會安裝」，而是「不知道有哪些 Skills 可以用」。
以前要找 Skills，可能要靠別人分享、GitHub 搜尋、社群文章，或自己慢慢翻各種資源庫。這種方式有幾個缺點：
很容易找不到真正適合的 Skill
搜尋過程會打斷目前工作流程
不知道哪些 Skill 比較可信
不知道該用什麼關鍵字搜尋
找到之後還要自己判斷怎麼安裝
find-skills 解決的就是這個問題。
它讓 Agent 可以根據目前任務，協助你搜尋、比較、推薦甚至安裝其他 Skills。換句話說，安裝它之後，你的 Agent 就不只是被動執行任務，而是能開始主動幫你擴充能力。
find-skills 是什麼？
find-skills 是 Vercel Labs Skills 專案中的一個官方 Skill。
官方頁面說明：https://github.com/vercel-labs/skills/blob/main/skills/find-skills/SKILL.md
它的主要功能是協助使用者從 open agent skills 生態系中發現與安裝 Skills。當你問 Agent「我要怎麼做某件事？」、「有沒有某種 Skill？」、「能不能幫我找某類工具？」時，find-skills 就可以派上用場。
它適合用在這些情境：
你想找某個特定用途的 Skill
你想知道某個任務是否已經有人做成 Skill
你想擴充 Agent 的能力
你想搜尋工具、範本或工作流程
你想讓 Agent 幫你推薦適合目前任務的 Skill
安裝 find-skills
建議直接使用 Vercel Labs 官方 Skills CLI 安裝。
npx skills add https://github.com/vercel-labs/skills --skill find-skills 這是我建議所有 Agent Skills 使用者第一個安裝的指令。
官方頁面：https://github.com/vercel-labs/skills/blob/main/skills/find-skills/SKILL.md
下載 / 安裝來源：https://github.com/vercel-labs/skills
SKILL.md 原始檔下載：https://raw.githubusercontent.com/vercel-labs/skills/main/skills/find-skills/SKILL.md
關鍵指令整理
安裝完成後，最常用的指令有以下幾個。
1. 搜尋 Skills
npx skills find "find skills" 也可以換成更具體的搜尋字，例如：
npx skills find "react performance"
npx skills find "seo meta"
npx skills find "pr review"
npx skills find "changelog"
npx skills find "wordpress" 搜尋關鍵字越具體，結果通常越準。
例如你要找 SEO 相關 Skills，不建議只搜尋：
可以改成：
npx skills find "seo meta"
npx skills find "seo tags"
npx skills find "wordpress seo" 這樣比較容易找到符合任務的 Skill。
2. 安裝 Skill
如果你已經知道要安裝哪個 Skill，可以使用：
例如：
npx skills add https://github.com/vercel-labs/skills --skill find-skills 3. 列出已安裝 Skills
這個指令可以查看目前已安裝的 Skills。
不過要注意，如果某些 Skills 不是透過 npx skills add 安裝的，可能不一定會被完整列出。
4. 檢查更新
這個指令可以檢查已安裝的 Skills 是否有更新。
5. 更新 Skills
這個指令會更新已安裝的 Skills。
建議不要盲目更新所有 Skills。更新前最好先確認來源是否可信、更新內容是否合理，尤其是在正式專案或公司環境中使用時，更應該謹慎。
使用 find-skills 的推薦流程
我會建議用這樣的流程：
Step 1：先描述你的需求
不要只丟一個太籠統的詞。
例如不要只說：
可以改成：
npx skills find "ui design system"
npx skills find "accessibility review"
npx skills find "figma to react" Step 2：查看搜尋結果
搜尋結果出現後，不要只看名稱。
建議至少確認：
Skill 名稱
來源作者或組織
安裝數
GitHub repo
是否有文件
是否近期仍有人維護
是否符合你的實際任務
Step 3：優先選可信來源
如果是正式專案使用，我會優先選擇這幾類來源：
官方組織
大型開源專案
GitHub 星數較高的專案
安裝數較多的 Skill
有清楚文件與範例的 Skill
不要只因為搜尋結果排在前面就直接安裝。
Step 4：安裝後再測試
安裝完成後，建議先用小任務測試。
例如你安裝了 SEO 相關 Skill，可以先讓 Agent 幫你產生一篇文章的：
SEO 標題
Meta description
WordPress 標籤
文章摘要
內部連結建議
確認結果符合預期後，再放進正式工作流程。
find-skills 適合哪些人？
我認為 find-skills 特別適合這幾種使用者。
1. 剛開始使用 Agent Skills 的人
你不需要一開始就知道所有 Skills。先裝 find-skills，讓 Agent 幫你找。
2. 經常做不同任務的開發者
如果你平常會做：
React
Next.js
WordPress
Docker
GitHub Actions
測試
部署
文件產生
Code Review
那 find-skills 很適合當成你的 Skill 搜尋入口。
3. 想打造個人 Agent 工作流的人
如果你希望 Agent 不只是聊天，而是變成真正的工作助理，Skills 會是很重要的擴充方式。
find-skills 則是幫你管理這個擴充入口的第一個工具。
4. 想建立團隊標準工具集的人
公司或團隊也可以先用 find-skills 找出常用 Skills，再建立自己的標準清單。
例如：
前端開發 Skills
測試 Skills
文件 Skills
DevOps Skills
SEO Skills
WordPress Skills
安全檢查 Skills
這樣可以讓團隊的 Agent 能力更一致。
使用 find-skills 的注意事項
find-skills 很方便，但不是所有搜尋結果都應該直接安裝。
使用時建議注意以下幾點。
1. 不要盲目相信搜尋結果
搜尋到 Skill，只代表它可能相關，不代表它一定適合你的任務。
正式使用前，仍然要確認來源、文件與內容。
2. 安裝前先看來源
尤其是來自不熟悉作者的 Skill，要更謹慎。
如果 Skill 會執行命令、讀寫檔案、存取專案內容，就更應該先檢查內容。
3. 搜尋關鍵字要具體
find-skills 的搜尋品質，很大程度取決於你的關鍵字。
比起搜尋：
更建議搜尋：
npx skills find "wordpress seo meta" 比起搜尋：
更建議搜尋：
npx skills find "playwright e2e test" 4. 更新 Skills 要小心
npx skills update 雖然方便，但在正式專案中不要隨便全部更新。
建議先檢查：
確認更新內容後，再決定是否更新。
我的建議：find-skills 是 Agent Skills 的第一個必裝工具
如果你只打算先安裝一個 Skill，我會選 find-skills。
因為它能讓 Agent 具備「找工具」的能力。
這跟一般單一功能 Skill 不一樣。一般 Skill 是讓 Agent 多一項能力，而 find-skills 是讓 Agent 開始知道「還有哪些能力可以被安裝」。
這也是為什麼我會把它稱為 Agent 的 Skill App Store。
先安裝它，之後要找 SEO、WordPress、React、測試、部署、文件、設計、Code Review 等 Skills，都會更有效率。
by Rain Chu 6 月 18, 2026 | AI , skills
skill-creator 是 Anthropic 官方 skills 專案中的一個 Skill 開發助手，可以協助使用者建立 Claude Code 可使用的自訂 Skill，透過 Skill，你可以把固定工作流程、專業知識、工具使用方式、文件格式與腳本包裝成可重複使用的能力，讓 Claude 在特定任務上更穩定、更一致，也更符合你的實際工作需求。
什麼是 Skill？
在 Claude Code 的使用情境中，Skill 可以理解成「給 AI 使用的操作說明書」。
它不是單純的一段 prompt，而是一個可重複使用的能力包。通常一個 Skill 會包含：
skill-name/
├── SKILL.md # 核心說明文件，必要
├── scripts/ # 可執行腳本，選用
├── references/ # 參考文件或知識資料，選用
├── assets/ # 圖片、範本、範例檔案等資源，選用 其中最重要的是 SKILL.md。
這個 Skill 是做什麼的
什麼情境下應該使用
要遵守哪些流程
輸出格式是什麼
是否需要使用特定工具、腳本或範本
簡單來說，Skill 的目標是讓 Claude 不只是「聽懂一次指令」，而是能長期穩定地執行某一類工作。
skill-creator 是什麼？
skill-creator 是 Anthropic 官方提供的 Skill 建立助手，收錄在官方 skills 專案中。
它的作用是協助你從零開始建立一個 Skill，包含：
釐清 Skill 的用途
設計觸發情境
撰寫 SKILL.md
建立參考文件
設計測試案例
評估 Skill 使用前後的效果
最後打包成 .skill 檔案
如果你只是手動寫 SKILL.md，很容易漏掉使用情境、輸出格式、邊界條件或測試流程。skill-creator 的價值就在於，它會像一個 Skill 顧問一樣，逐步問你問題，幫你把需求整理成可以實際使用的 Skill。
官方網頁與下載連結
官方 GitHub 專案：https://github.com/anthropics/skills/tree/main
skill-creator 官方目錄：https://github.com/anthropics/skills/tree/main/skills/skill-creator
下載 Anthropic skills 專案 ZIP：https://github.com/anthropics/skills/archive/refs/heads/main.zip
安裝 skill-creator
如果你已經在使用 Claude Code，可以透過以下方式安裝 skill-creator。
方法一：使用 npx skills add
npx skills add https://github.com/anthropics/skills --skill skill-creator 方法二：使用 claude install
claude install anthropics/skills/skill-creator 安裝完成後，就可以在 Claude Code 中呼叫：
接著 Claude 會開始引導你建立 Skill。
用 skill-creator 建立 Skill 的基本流程
使用 skill-creator 建立 Skill，通常可以分成以下幾個階段。
1. 說明你想建立的 Skill
一開始，你可以用自然語言描述需求，例如：
我想建立一個 Skill，用來把會議逐字稿整理成結構化會議紀要。 或是：
我想建立一個 Skill，用來分析 WordPress 網站錯誤訊息，並提供排查步驟。 這時候不需要一次寫得非常完整，因為 skill-creator 會繼續追問細節。
2. 回答 skill-creator 的需求問題
skill-creator 通常會確認幾個重點：
這個 Skill 主要要完成什麼任務？
使用者在什麼情境下會觸發它？
輸入資料可能是文字、檔案、程式碼還是圖片？
輸出格式要用 Markdown、表格、JSON、Word 文件，還是其他格式？
是否有固定流程、固定語氣或固定檢查清單？
是否需要使用特定工具、腳本或外部文件？
這一步非常重要。
3. 自動產生 SKILL.md 草稿
確認需求後，skill-creator 會協助產生 SKILL.md。
一個基本的 SKILL.md 會長得像這樣：
---
name: meeting-minutes
description: Convert meeting transcripts into structured meeting minutes with decisions and action items.
---
# Meeting Minutes Skill
Use this skill when the user provides a meeting transcript and wants a structured meeting summary.
## Output Format
Include the following sections:
1. Meeting topic
2. Date and time
3. Participants
4. Key discussion points
5. Decisions
6. Action items with owner and deadline
## Guidelines
- Keep the summary concise.
- Preserve important decisions.
- Do not invent missing attendees or dates.
- If information is missing, mark it as "未提供". 這份 SKILL.md 就是 Claude 之後使用 Skill 時會讀取的核心說明。
4. 加入參考資料與範本
如果你的 Skill 需要固定格式，可以把範本放進 references/ 或 assets/。
例如：
meeting-minutes/
├── SKILL.md
├── references/
│ └── meeting-template.md
├── assets/
│ └── company-style-guide.pdf 常見的參考資料包括：
公司品牌規範
文件格式範本
常用表格
API 使用說明
程式碼規範
工作流程 SOP
檢查清單
這樣 Claude 在執行任務時，不只會依照 prompt 回答，也會參考 Skill 內部的固定資料。
5. 設計測試案例
建立 Skill 後，最好不要馬上投入正式工作，而是先做測試。
你可以準備幾組測試資料，例如：
測試一：正常格式的會議逐字稿
測試二：缺少參與人資訊的會議紀錄
測試三：內容很長、決議很多的會議
測試四：只有零散重點，沒有完整逐字稿 測試的目的不是只看 Claude 有沒有回答，而是要比較：
有使用 Skill 時，結果是否更穩定？
輸出格式是否一致？
是否遵守你指定的規則？
是否能處理邊界情況？
是否有少編造、少漏項？
6. 根據測試結果修改 Skill
第一次產生的 Skill 通常不會完美。
常見需要調整的地方包括：
描述太模糊，導致 Claude 不知道何時使用
輸出格式不夠明確
邊界條件沒有寫清楚
範例太少
沒有說明錯誤情況要怎麼處理
沒有限制 Claude 不要自行補資料
建議你把 Skill 當成一份「可持續最佳化的 SOP」。SKILL.md。
7. 打包成 .skill 檔案
當 Skill 測試穩定後，就可以打包成 .skill 檔案，方便匯入、分享或部署。
打包後的 Skill 就像一個可攜式能力包，可以用在支援 Skill 的 Claude 環境中。
skill-creator 適合用在哪些情境？
skill-creator 很適合用來建立以下類型的 Skill：
文件處理類
例如：
會議紀要整理
合約摘要
報告格式化
WordPress 部落格文章產生
SEO 文章檢查
論文格式整理
開發工作類
例如：
Code Review
安全檢查
API 文件產生
Git commit message 規範
Docker 部署檢查
WordPress 錯誤排查
企業流程類
例如：
客服回覆 SOP
品牌語氣檢查
行銷企劃產生
業務提案格式
專案週報整理
個人自動化類
例如：
每週工作回顧
讀書筆記整理
投資研究筆記格式化
學習計畫產生
旅遊規劃模板
建立 Skill 時的實用建議
1. description 要寫清楚
description 不只是說明文字，它會影響 Claude 判斷什麼時候該使用這個 Skill。
不建議這樣寫：
建議改成：
description: Use this skill when the user provides meeting transcripts and wants structured meeting minutes with decisions, discussion points, and action items. 越清楚，Claude 越容易正確觸發。
2. 輸出格式要固定
如果你想要表格，就直接指定表格欄位。
例如：
## Output Format
Return the result in Markdown with the following sections:
# 會議紀要
## 一、會議基本資訊
## 二、討論重點
## 三、決議事項
## 四、待辦事項 3. 明確說明不要編造資料
這一點很重要，尤其是處理會議、合約、財務、法律或客戶資料時。
可以在 Skill 中加入：
## Accuracy Rules
- Do not invent missing information.
- If a field is not provided, write "未提供".
- Preserve names, dates, numbers, and deadlines exactly as given. 4. 加入好範例與壞範例
Skill 裡面可以放 Examples，讓 Claude 更容易理解你要的品質。
例如：
## Examples
Good:
- Clear action item with owner and deadline.
- Concise summary without unnecessary commentary.
Bad:
- Inventing a deadline that was not mentioned.
- Mixing discussion points with final decisions. 常用指令整理
安裝 skill-creator
npx skills add https://github.com/anthropics/skills --skill skill-creator 使用 claude install 安裝
claude install anthropics/skills/skill-creator 呼叫 skill-creator
從官方 GitHub 下載 skills 專案
git clone https://github.com/anthropics/skills.git 或直接下載 ZIP：
https://github.com/anthropics/skills/archive/refs/heads/main.zip 做好 Skill 後，如何移植到其他系統？
建立好 Skill 之後，不一定只能放在 Claude Code 裡使用。
不過要注意一件事：Skill 的核心不是某一個平台的格式，而是裡面的工作流程、判斷規則、輸出格式、參考資料與可執行腳本。
也就是說，真正有價值的是這些內容：
SKILL.md
references/
scripts/
assets/
examples/
只要把這些內容轉成目標 Agent 系統可以讀懂的格式，就可以完成移植。
Skill 移植的核心概念
一個 Skill 通常可以拆成五個部分：
1. 任務說明：這個 Skill 是做什麼的
2. 觸發條件：什麼情況下應該使用
3. 操作流程：執行任務時要照什麼步驟
4. 輸出格式：最後要產生什麼格式
5. 工具資源：是否需要腳本、範本、參考文件或 API
不同 Agent 系統的格式可能不同，但這五個部分通常都可以保留下來。
因此，移植 Skill 的重點不是「直接複製檔案」，而是把原本的 SKILL.md 改寫成目標系統的規則檔、角色設定、工具說明或 system prompt。
建議的 Skill 通用資料夾結構
為了方便未來移植，建議你在建立 Skill 時，就使用比較通用的結構：
my-skill/
├── SKILL.md
├── README.md
├── references/
│ └── knowledge-base.md
├── examples/
│ ├── input-1.md
│ └── output-1.md
├── scripts/
│ └── helper.py
├── assets/
│ └── template.md
└── manifest.json
其中：
SKILL.md：給 Claude 或支援 Skill 的 Agent 使用README.md：給人類維護者閱讀references/：放背景知識、規則、範本examples/：放輸入與輸出範例scripts/：放可執行工具assets/：放模板、圖片、表格等資源manifest.json：給其他 Agent 系統讀取的設定檔
如果你未來要移植到 Hermes Agent 或 Codex，這種結構會比較容易轉換。
範例：建立一個通用 manifest.json
可以在 Skill 裡面額外放一個 manifest.json，用來描述這個 Skill 的基本資訊。
{
"name": "wordpress-seo-writer",
"version": "1.0.0",
"description": "Generate Traditional Chinese WordPress blog posts with SEO title, tags, meta description, and structured article format.",
"language": "zh-TW",
"entry": "SKILL.md",
"references": [
"references/seo-guidelines.md"
],
"examples": [
"examples/input-1.md",
"examples/output-1.md"
],
"tools": [
{
"name": "keyword_checker",
"type": "script",
"path": "scripts/keyword_checker.py"
}
]
}
這個檔案不一定是 Claude Code 必要的，但它很適合給自建 Agent 系統使用。manifest.json，知道這個 Skill 的名稱、用途、入口檔案、參考資料與可用工具。
移植到 Hermes Agent
如果你使用的是自建的 Hermes Agent，建議把 Skill 當成一個「Agent 能力模組」來管理。
可以設計成以下結構：
hermes-agent/
├── agents/
│ └── writer-agent/
│ ├── system.md
│ ├── tools.json
│ └── skills/
│ └── wordpress-seo-writer/
│ ├── SKILL.md
│ ├── manifest.json
│ ├── references/
│ ├── examples/
│ └── scripts/
Hermes Agent 在執行任務時，可以做三件事：
1. 根據使用者輸入，判斷是否需要啟用某個 Skill
2. 讀取該 Skill 的 SKILL.md 與 references/
3. 將 Skill 內容合併進 Agent 的 system prompt 或 task prompt
例如使用者輸入：
請幫我寫一篇 WordPress SEO 文章，主題是 skill-creator。
Hermes Agent 可以比對 Skill 的 description，找到 wordpress-seo-writer，然後載入：
skills/wordpress-seo-writer/SKILL.md
skills/wordpress-seo-writer/references/seo-guidelines.md
skills/wordpress-seo-writer/examples/output-1.md
接著再讓模型依照這些規則產生文章。
Hermes Agent 的 Skill 載入邏輯範例
如果是自己開發 Hermes Agent，可以用簡單的流程實作：
User Request
↓
Intent Router
↓
Skill Matcher
↓
Load SKILL.md
↓
Load references / examples / scripts
↓
Compose Agent Prompt
↓
Run Model
↓
Return Result
也可以設計一個簡單的 Skill Registry：
{
"skills": [
{
"name": "wordpress-seo-writer",
"description": "Write Traditional Chinese WordPress SEO articles.",
"path": "./skills/wordpress-seo-writer",
"trigger_keywords": [
"WordPress",
"SEO文章",
"部落格文章",
"中繼描述",
"標籤"
]
},
{
"name": "code-review-security",
"description": "Review code for security, maintainability, and deployment risks.",
"path": "./skills/code-review-security",
"trigger_keywords": [
"code review",
"安全檢查",
"漏洞",
"重構"
]
}
]
}
這樣 Hermes Agent 就可以根據關鍵字、語意比對或任務分類，自動決定要不要載入某個 Skill。
移植到 Codex
如果要移植到 Codex，建議分成兩層處理：
1. 專案層級規則：放進 AGENTS.md
2. 任務型 Skill：保留成獨立 Skill 資料夾
Codex 會讀取專案中的 AGENTS.md，因此可以把與專案相關的固定規則放在這裡，例如：
# AGENTS.md
## Project Rules
- Use Traditional Chinese when writing user-facing documentation.
- Do not modify database schema unless explicitly requested.
- Before changing code, inspect the existing architecture.
- Prefer small, reviewable changes.
- When writing WordPress articles, use the wordpress-seo-writer skill.
而真正的 Skill 內容則可以保留在專案目錄中：
project/
├── AGENTS.md
├── skills/
│ └── wordpress-seo-writer/
│ ├── SKILL.md
│ ├── references/
│ ├── examples/
│ └── scripts/
這樣做的好處是：
AGENTS.md 負責專案整體規則SKILL.md 負責特定任務流程references/ 保存知識與格式scripts/ 保存可重複使用的工具
Codex 使用 Skill 的建議方式
如果 Skill 是用來處理開發工作，例如 Code Review、安全檢查、部署檢查，建議把 Skill 寫得更像工程 SOP。
例如：
# Code Review Security Skill
Use this skill when reviewing code changes for security, maintainability, and deployment risks.
## Review Checklist
1. Authentication and authorization
2. Input validation
3. SQL injection risk
4. Secrets and environment variables
5. File upload handling
6. Error handling
7. Logging and privacy
8. Deployment risk
## Output Format
Return the review in this format:
# Code Review Report
## Summary
## Critical Issues
## Medium Issues
## Low Risk Suggestions
## Recommended Patch
## Test Plan
然後在 AGENTS.md 裡加入：
## Skills
When the task involves security review, load:
skills/code-review-security/SKILL.md
這樣 Codex 在處理程式碼任務時，就可以依照固定流程執行，而不是每次都靠臨時 prompt。
Claude Skill、Hermes Agent、Codex 的對應關係
Skill 內容 Claude Code Hermes Agent Codex 任務說明 SKILL.md description manifest.json description AGENTS.md 或 Skill description 操作流程 SKILL.md system prompt / task prompt AGENTS.md / Skill 參考資料 references/ knowledge base / RAG project docs / references/ 腳本工具 scripts/ tools / function calling scripts / shell tools 輸出格式 SKILL.md response schema AGENTS.md / task instruction 測試案例 examples/ evaluation set test prompts / eval cases
移植時最容易出問題的地方
1. Skill 觸發條件不清楚
如果 description 寫得太模糊，Agent 不知道什麼時候該使用。
不建議：
建議：
當使用者要求撰寫 WordPress SEO 部落格文章，且需要標題、標籤、中繼描述與繁體中文內容時，使用此 Skill。
2. 原本依賴 Claude 的功能，其他系統沒有
有些 Skill 可能假設 Claude Code 可以讀檔、執行 script 或打包 .skill。
讀取本地檔案
執行 shell 指令
呼叫 Python 腳本
使用 MCP server
使用 function calling
存取 Git repo
存取外部 API
如果不支援，就要改成純文字流程，或另外做工具橋接。
3. references 太大，模型上下文放不下
如果參考文件很多，不建議一次全部塞進 prompt。
1. 先用 Skill description 判斷要不要使用
2. 再根據任務讀取必要 references
3. 只載入與當前任務相關的段落
這樣可以避免上下文太長，也能提升回答品質。
4. 腳本路徑與執行環境不同
例如你在 Claude Code 裡用的是：
但移植到 Hermes Agent 的 Docker 環境後，可能要改成：
python /app/skills/wordpress-seo-writer/scripts/check.py
因此建議在 manifest.json 中明確寫出腳本路徑、執行方式與依賴套件。
建議：把 Skill 設計成可攜式能力包
如果你一開始就希望 Skill 可以移植到 Claude Code、Hermes Agent、Codex 或其他 Agent 系統，建議遵守以下原則：
1. SKILL.md 不要寫死特定平台專用語法
2. 把平台相關設定放到 adapters/ 目錄
3. 把核心流程寫在 core.md
4. 把範例輸入輸出放到 examples/
5. 把工具設定放到 manifest.json
可以設計成：
portable-skill/
├── core.md
├── SKILL.md
├── manifest.json
├── adapters/
│ ├── claude-code.md
│ ├── hermes-agent.md
│ └── codex-agents.md
├── references/
├── examples/
└── scripts/
其中：
core.md：保存跨平台共用的核心流程SKILL.md：給 Claude Code 使用manifest.json：給自建 Agent 系統使用adapters/claude-code.md：Claude Code 專用說明adapters/hermes-agent.md：Hermes Agent 專用說明adapters/codex-agents.md：Codex 專用說明
這樣同一個 Skill 就不會被綁死在單一平台上。
移植檢查清單
在把 Skill 移到其他 Agent 系統前，可以用這份清單檢查：
□ Skill 的用途是否明確？
□ description 是否能讓 Agent 判斷何時使用？
□ 輸入格式是否定義清楚？
□ 輸出格式是否固定？
□ 是否有 examples？
□ 是否有 references？
□ references 是否可以被目標系統讀取？
□ scripts 是否能在目標環境執行？
□ 是否需要 API key 或環境變數？
□ 是否有測試案例？
□ 是否有平台專用 adapter？
□ 是否避免把敏感資訊寫進 Skill？
Skill 應該被設計成 Agent 的可攜式 SOP
skill-creator 產生的 Skill，最好不要只當成 Claude Code 的專用檔案。
Claude Code 可以使用 SKILL.md。manifest.json、references/ 與自訂 router。AGENTS.md、專案規則與 Skill 資料夾來載入任務流程。
只要核心流程設計清楚，Skill 就可以成為跨 Agent 系統共用的能力包，讓同一套工作方法在不同 AI 工具之間延續使用。
近期留言