by Rain Chu | 7 月 9, 2026 | AI, skills
很多 AI Agent 做不好，不是因為模型太弱，而是任務在一開始就太模糊，使用者一句「幫我做一個工具」、「幫我寫一個遊戲」、「幫我規劃一個工作流」，Agent 會很認真地往前衝，但它其實是在替你補完一堆你沒有講清楚的決策。
Grill Me 這類 skill 的價值，就在於把「開工前的需求訪談」變成固定流程，它不急著執行，而是先反過來問你：目標是什麼？使用者是誰？限制在哪裡？哪些選項還沒決定？什麼事情一定不能做？這一步看起來慢，實際上是在幫你省掉後面反覆重做的時間。
如果你已經在用 Codex、Claude Code、Cursor、Windsurf 或 OpenCode 這類工具，這篇可以當成一個提醒：真正拉開成果差距的，不只是模型版本，而是你有沒有一套讓 Agent 開始前先釐清需求的工作流。站上之前整理過 OpenWork / OpenCode 桌面工作台，那偏向執行環境，這篇談的是執行前的需求對齊。
先講結論：不要太快叫 Agent 開始做事
AI Agent 最常見的失控點，是使用者以為自己已經講清楚，但其實只講了一個方向，人類同事遇到模糊需求，可能會回頭問你，Agent 則常常直接開做，做出一個看起來完整、但不是你真正想要的東西。
Grill Me 的做法很簡單：在實作前先訪談。它會針對任務目標、使用場景、輸出格式、限制條件、技術選擇、驗收標準一路追問，直到這個任務足夠明確，Agent 才開始真正執行。
這不是把 prompt 寫長而已，而是把「需求還沒完成」這件事明確暴露出來，對我來說，這是使用 AI Agent 很重要的一個分水嶺：你不是把一段模糊想法丟給模型猜，而是先和模型一起把決策樹走完。
Grill Me 是什麼？
Grill Me 來自 Matt Pocock 的 skills 倉庫，這個倉庫不是單一工具，而是一組可安裝到 AI coding agent 裡的工作流程 skill，包含需求訪談、文件對齊、規格整理、TDD、debugging、code review 等。
我在 2026 年 7 月 9 日查看 GitHub API 時，這個倉庫已經超過 16 萬顆星，授權是 MIT，README 裡的定位也很明確：這些 skill 是小型、可調整、可組合的流程，而不是把整個開發過程交給一套巨大框架接管。
Grill Me 本身很短，核心是啟動一段 grilling session，也就是讓 Agent 對你的計畫或設計進行密集訪談。它不是替你做決策，而是逼你把原本藏在腦袋裡的決策說出來。
為什麼「需求訪談」會讓結果差很多？
用「做一個側邊欄貪食蛇遊戲」這種需求來看，沒有訪談時，Agent 也能做出一個可玩的版本。它可能有開始按鈕、分數、速度調整，也能用鍵盤操作。表面上看起來不差。
但只要開始追問，需求會變得完全不一樣：這個側邊欄是 Codex 裡的小工具，還是瀏覽器側邊欄？它是一次性 demo，還是要固定留下來？等待 Agent 工作時能不能玩？鍵盤焦點可能不在遊戲上，是否需要畫面按鈕保底？撞牆要不要死亡？分數要不要保存？記錄要不要能清除？
這些問題不是細枝末節，而是產品體驗的骨架。當它們沒有被問出來，Agent 只能照自己的預設做，當它們被問出來，Agent 才能把設計、互動、資料保存、通知機制都接到同一個使用情境上。
一個好用的 Grill Me 流程，應該問哪些問題？
我會把這類訪談問題分成七組。你不一定要每次問滿，但至少要讓 Agent 在開工前碰過這些維度。
- 目標：這次任務真正要改善什麼？成功之後看起來是什麼樣子？
- 受眾：誰會使用這個成果？是自己用、團隊用、客戶用，還是公開產品？
- 場景：使用者會在什麼時間、什麼裝置、什麼流程裡使用它？
- 限制：不能用哪些技術？不能改哪些檔案？不能花太多時間在哪裡？
- 輸出：最後要交付文章、程式、規格、PRD、測試、圖片，還是一組可執行步驟？
- 驗收：怎樣才算完成？要不要測試？要不要截圖？要不要能回滾？
- 禁區：哪些事情不要做？哪些語氣、設計、依賴、資料來源要避開？
站上之前寫過 CO-STAR prompt 框架，那套方法適合把指令寫得更完整；Grill Me 則更像互動式版本，讓 Agent 透過追問幫你補齊缺口。
Matt skills 倉庫才是核心資源
Matt Pocock 的 skills 倉庫。這個連結比一般工具推薦更重要，因為 Grill Me 不是孤立存在，它其實是整套工作流的一個入口。
這套 skill 大致分成 engineering 和 productivity，Grill Me 屬於 productivity，適合非程式任務或早期想法釐清；Grill with Docs 則偏 engineering，會把訪談結果延伸到專案文件、domain model、ADR 等長期維護資料。
這也呼應我之前整理的 Matt Pocock Skills 工作流：真正有價值的不是某個單點技巧，而是把訪談、規格、測試、程式碼審查變成一套固定節奏。
Grill Me 不是讓 AI 變聰明，而是讓任務變清楚
用了 Grill Me，不代表模型突然變成更高階版本，也不代表結果一定完美，它真正改善的是「任務定義品質」。
模糊任務的問題在於，Agent 會把大量隱性選擇變成自己的預設，比方說你說「做一個工具」，它要猜是網頁、CLI、桌面 app 還是瀏覽器插件；你說「幫我寫文章」，它要猜讀者是新手、工程師、主管還是 SEO 流量；你說「做得好看」，它要猜品牌、風格、資訊密度、互動狀態。
Grill Me 把這些猜測改成問題。當問題被回答，Agent 的輸出就不再只是「通用答案」，而會更貼近你的真實情境。
我會怎麼把 Grill Me 放進自己的 Codex 流程？
如果是新專案，我會把流程拆成四步。
- 第一步，用 Grill Me 釐清需求。先不要寫程式，先讓 Agent 問到目標、限制、驗收方式都清楚。
- 第二步，把訪談整理成規格。可以轉成 PRD、spec 或 issue，避免後面上下文掉失。
- 第三步，用 TDD 或驗收清單鎖住品質。讓 Agent 先知道什麼叫完成，而不是做完才補救。
- 第四步，讓 code review / debug 流程收尾。不要把「看起來能跑」當成完成。
這條路線和 用 Superpowers 建立 AI 開發紀律的方向很接近：不要把 Agent 當一次性神諭，而是把它放進一套有檢查點、有回饋、有驗收的流程。
安裝 skill 前，先想清楚你要它解決什麼問題
很多人看到 skill 倉庫，第一反應會是全部安裝。這可以，但我更建議先從自己的痛點倒推。
如果你常常覺得 Agent 做出來的東西方向不對，先試 Grill Me。若你已經有專案文件，但 Agent 老是誤解術語和架構，可以研究 Grill with Docs。若你遇到的是改一處壞三處，TDD 和 debugging 類 skill 會更有幫助。
如果你想自己建立類似流程，也可以回頭看 用 skill-creator 建立自訂技能。真正好用的 skill，通常不是把所有規則塞滿，而是把一個高頻問題變成可重複執行的流程。
可以直接拿去用的 Grill Me 提示詞
如果你還沒安裝 skill，也可以先用下面這段作為替代版，它不如正式 skill 可維護，但已經能改善很多「太快開工」的問題。
在開始執行前，請先訪談我。
你要把我的需求問清楚，而不是直接開始做。
請一次只問 1 到 3 個最關鍵的問題。
每個問題請附上你的推薦答案，以及為什麼你推薦這樣選。
當你認為需求、限制、輸出格式、驗收標準都足夠清楚後，
請先整理一份任務規格給我確認。
等我明確說「開始執行」之後，你才可以動手。
這段的重點有三個：一次不要問太多、問題要附推薦答案、最後要整理成規格再等確認，這樣做可以避免 AI 把訪談變成問卷疲勞，也能讓使用者比較快做決策。
AI Agent 的品質，常常卡在開工前
Grill Me 給我的最大提醒是：不要把所有問題都歸咎於模型。很多時候，Agent 不是不會做，而是它根本不知道你真正要的是哪一種成果。
需求訪談不是形式，它是把模糊想法變成可執行任務的過程。當目標、場景、限制、輸出和驗收都被問清楚，Agent 才有機會交出真正能用的結果。
我會把 Grill Me 放在 AI Agent 工作流的第一關。不是因為它很華麗，而是因為它解決了一個最基本、也最常被忽略的問題：開始之前，先確定大家要做的是同一件事。
延伸資源
by Rain Chu | 6 月 18, 2026 | AI, skills
前言：AI 編碼不是「一句 Prompt 就完成」
用 Claude Code、Codex、Cursor、Gemini CLI 或其他 AI Coding Agent 來開發
一開始看起來很神奇：
輸入需求，AI 產生程式碼；
丟進錯誤訊息，AI 幫忙修 Bug；
給它一個功能描述，它甚至可以幫你改好整個模組。
但實際進入專案後，問題也很快浮現：
AI 寫出來的程式碼不一定符合需求。
AI 常常講太多，卻沒有抓到專案真正的語言。
AI 產出的程式碼看起來合理，但跑不起來。
AI 加速了開發，也同時加速了技術債。
這正是 Matt Pocock 開源 skills 專案想解決的問題。
Matt Pocock 在官方 GitHub 專案中寫下這句話：
Skills for Real Engineers. Straight from my .claude directory.
這句話很關鍵。
它不是在說「給 AI 更多 Prompt」。
而是在說：把真實工程師每天會做的判斷、流程、檢查與紀律，包裝成可重複使用的 Skill，讓 AI Agent 不是單純寫程式，而是按照工程流程做事。
什麼是 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 編碼不是取代軟體工程，而是更需要軟體工程。
AI 編碼痛點一：Agent 沒有真正理解需求
問題
AI Coding 最常見的失敗，不是語法錯誤，而是「它做的不是你要的」。
你可能請 AI 做一個後台報表頁面。
AI 可能很快生成 UI、API、資料表與測試。
但等你看完結果才發現：
- 欄位不是老師真正需要看的欄位
- 查詢條件不符合業務流程
- 權限設計漏掉角色差異
- 空狀態、錯誤狀態、邊界案例沒有處理
- 它理解的「報表」跟你理解的完全不同
這不是 AI 不聰明，而是需求沒有對齊。
對應 Skill：/grill-me 與 /grill-with-docs
Matt Pocock 的解法是：
在寫程式前，先讓 AI 反問你。
/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。
它會要求 Agent 依照更有紀律的流程處理問題：
- 重現錯誤
- 最小化案例
- 提出假設
- 加入觀測與紀錄
- 修正問題
- 補上回歸測試
這比直接叫 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 的用途是掃描程式碼庫，找出架構可以改善的地方。
它不是單純叫 AI 重構，而是先分析：
- 哪些模組太淺
- 哪些抽象不夠穩定
- 哪些介面太大
- 哪些責任混在一起
- 哪些地方不容易測試
- 哪些功能應該被拆成更深的模組
codebase-design 則提供一套讓 AI 判斷模組設計的語言。
核心精神是：好的模組應該把複雜行為包在簡單介面後面。
這對 AI Coding 非常重要。
因為 AI 很容易局部最佳化，卻忽略整體設計。
實務建議
如果你的 AI Agent 已經連續幫你開發好幾天，建議定期執行：
/improve-codebase-architecture
可以設定成每幾天做一次架構健檢，尤其是在以下情境：
- 新功能大量加入後
- 多個 Agent 平行開發後
- 頁面開始變得難維護
- 測試越來越難寫
- 開發者開始不確定邏輯應該放哪裡
- 同一種資料轉換出現在很多檔案中
AI 不只應該幫你加功能，也應該幫你守住系統結構。
一張圖看懂 Matt Pocock Skills 工作流
可以把這套流程想成四個階段：
這個流程的重點不是工具本身，而是節奏。
AI 不應該一次吃下整個專案。
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
第一次導入時使用。
用來設定 Issue Tracker、標籤、文件位置與專案工作流。
/grill-me
讓 AI 針對你的想法進行深入提問。
適合非程式碼需求、產品想法、設計方向。
/grill-with-docs
進階版需求釐清。
除了問問題，也會協助建立上下文文件與架構決策紀錄。
/to-prd
把目前對話整理成 PRD。
適合在需求已經大致釐清後使用。
/to-issues
把 PRD、計畫或規格拆成可執行的 Issues。
重點是拆成垂直切片，而不是技術分工清單。
/tdd
用測試驅動開發方式完成任務。
適合功能開發與 Bug 修復。
/diagnosing-bugs
用紀律化方式診斷 Bug。
適合複雜錯誤、效能問題與回歸問題。
/improve-codebase-architecture
掃描程式碼庫並提出架構改善方向。
適合定期做技術債整理。
git-guardrails-claude-code
設定 Git 安全防護，避免 Agent 執行危險 Git 指令。
例如阻擋 reset --hard、clean 或不該執行的 push 行為。
為什麼這套方法值得關注？
Matt Pocock Skills 的重點，不是發明一個全新的 AI 工具。
它真正有價值的地方，是把「工程師本來就該做的事」變成 AI 可以遵循的工作流。
它提醒我們：
AI 不缺寫程式碼的能力。
AI 缺的是上下文、回饋、邊界、命名、架構與驗證。
而這些東西，正是軟體工程的核心。
如果你只把 AI 當成程式碼產生器，它很快會帶來混亂。
如果你把 AI 當成需要被管理、被引導、被驗證的工程協作者，它就能變成很強的開發加速器。
AI Coding 的下一步，是工作流工程化
AI 編碼正在從「Prompt 技巧」進入「工作流設計」。
早期大家在比較誰的 Prompt 寫得好。
現在真正重要的是：
- 有沒有清楚的需求釐清流程
- 有沒有穩定的專案上下文
- 有沒有測試回饋
- 有沒有架構守門
- 有沒有 Issue 拆解
- 有沒有安全邊界
- 有沒有讓人類重新介入審查的節點
Matt Pocock 的 Skills 專案，正好提供了一個很好的起點。
它不是叫你把專案完全交給 AI。
它是讓 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
第一次一定要選。
這是初始化 Matt Pocock Skills 工作流用的，會幫你建立專案設定、issue tracker、文件位置等基本配置。
2. grill-with-docs
用來讓 AI 先問清楚需求，不要一開始就亂寫 code。
很適合你現在的 AI Grader、WordPress、SaaS、工具頁面開發。
3. to-prd
把討論內容整理成 PRD。
適合把「想法」轉成產品需求文件。
4. to-issues
把 PRD 拆成一個一個可執行的 issue。
這很重要，因為 AI 最怕一次任務太大。
5. tdd
用測試驅動開發方式實作。
讓 AI 先寫測試，再寫功能，比較不容易寫出看起來對、實際不能跑的程式碼。
6. diagnosing-bugs
Debug 專用。
遇到錯誤時，不要讓 AI 直接亂猜修法，而是要求它先重現、分析、找 root cause。
7. improve-codebase-architecture
定期檢查專案架構。
AI 寫久了很容易讓專案變成一團泥球，這個 skill 用來做架構整理。
8. codebase-design
用來建立或檢查程式碼設計原則。
適合你要讓 AI 理解「這個專案的架構應該怎麼長」。
第二批可以考慮加裝
等你開始穩定使用後，再加這些：
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
不是不好，而是它們比較偏教學、寫作、知識整理或特殊用途。
你現在如果目標是 AI Grader / WordPress / SaaS / Claude Code 開發流程，先不用裝那麼多。
實戰開發組合的選法
可以先這樣選：
[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
近期留言