給人手動呼叫的入口。現行內容只負責啟動共用訪談迴圈。
disable-model-invocation: true
01 · 目前架構
現行版不是「五行魔法」，而是三層可組合結構
Matt 把手動入口、可重用訪談行為、程式庫 文件化拆開。這正是小型 技能 的價值：每一層只負責一件事，行為只有一個真實來源。
真正的行為核心：逐題追問、附建議、先查事實、等人類確認。其他 技能 也可以重用。
model-invoked primitive
Codebase 專用入口：執行 grilling，同時用 domain-modeling 維護術語與重要決策。
grilling + domain-modeling
版本修正：「打開 grill-me 會看到完整五行指令」已不是 2026-07-23 GitHub 即時版本 的真實結構。現在 包裝入口 只有一行，完整規則移到 `grilling`，這是為了 唯一可信來源 與重用。
02 · 運作規則
五項規則少一項，就不算真的 Grill Me
判斷 代理 有沒有照做，不是看它問了幾題，而是看問題的順序、資訊來源、建議品質與停止條件。
一次只問一題
每次處理最重要的未決項目，等回答後才走下一個分支。
檢查點：不能一次丟十題問卷。
沿決策樹往下
先解上游選擇，再問受它影響的下游問題，避免順序顛倒。
檢查點：每題應能說明為何現在要問。
每題附建議答案
代理 不只把思考工作丟回來，還要提供推薦選項、理由與取捨。
檢查點：有 建議，不是空泛追問。
事實自己查
檔案位置、現有行為、API、程式流程等可查事實，由 代理 探索環境取得。
檢查點：只把真正需要人類拍板的 決策 問你。
確認前不動工
達成 共同理解 並由人類確認前，不寫 程式碼、不改設定、不開始實作。
檢查點：有明確 核准關卡。
03 · AI Agent 工作流程範例
同一句需求，直接做與先釐清的結果差很多
以下以「讓內容輸出 代理 自動交付最新教學檔」為例。真正重要的不是多問，而是先抓出會改變安全性與使用方式的上游決策。
「多加一個按鈕，把最後一個檔案寄到我信箱。」
- 「最後一個」依建立時間、修改時間，還是已確認的正式版本？
- 寄件前要不要預覽與確認？
- 哪些檔案類型可以寄？
- 收件人是否固定？寄送前如何確認？
- 寄送失敗如何顯示與重試？
Agent
「最新檔案」要以哪個來源為準？建議：先指定一份已確認的正式版本，比只看檔案修改時間可靠。
Michael
就用 最新匯出版本。
Agent
按下後要直接寄，還是先顯示收件人與檔名？建議：先清楚顯示收件人和檔名，讓使用者確認後再寄送，降低寄錯風險。
04 · 從想法到交付
Grill Me 只是入口，後面要接可驗證的工程流程
每個 技能 只完成一個明確工作。需求已經清楚時可以從中間開始，不需要為了遵守形式把整條線重跑。
把未決問題、限制、取捨與人類決策問清楚。
把共識整理成問題、方案、用戶故事、決策、測試與邊界。
拆成可獨立驗證的 可貫通流程的驗收票，標出 阻擋相依關係。
只依已確認 spec / ticket 實作，不重新發明需求。
在預先同意的 模組邊界 上，一次完成一個 red → green 垂直切片。
分開檢查 工程標準 與 需求規格，避免「寫得漂亮但做錯需求」。
正確分流：沒有 程式庫 的一般想法用 `grill-me`；已經在專案裡做功能、架構或領域設計，使用 `grill-with-docs`。後者會把 標準術語 寫入 `CONTEXT.md`，只有難以逆轉、令人意外且存在真實取捨的決策才值得 ADR。
05 · 目前技能組合
不是所有 技能 都自動跑：Matt 刻意分成「流程入口」與「工程紀律」
這是前一版最需要說清楚的地方。官方 `main` 以 `disable-model-invocation` 區分誰能啟動：手動入口控制階段，自動 技能 只在任務符合時提供可重用紀律。全部一起觸發反而會增加 隨機 行為。
grill-with-docs
你口述的「grow with stacks」最可能是這個。用於已有 程式庫 的需求釐清，同時維護 `CONTEXT.md` 與必要 ADR。
to-spec
把已經談清楚的對話整理成 spec。它不應重新訪談，也不應直接實作。
to-tickets
你說的「to check it」正確名稱是 `to-tickets`。它把 spec 拆成可獨立驗證的 可貫通流程的驗收票，並標示 阻擋相依關係。
implement
只在 spec 或 tickets 已核准後執行；內部使用 TDD，完成後再跑 code-review，最後才 commit。
tdd
對可測行為執行 red → green → refactor。測公開行為，不綁死內部實作。
code-review
從固定基準點比較 diff，分開檢查 工程標準 與 需求規格，避免程式碼品質掩蓋需求偏差。
diagnosing-bugs
先建立會穩定變紅的重現迴圈，再最小化、假設、觀測、修復與回歸測試；不靠猜測直接改。
improve-codebase-architecture
掃描 deep-module 改善機會並產生視覺報告。先選候選項，再回到 grill-with-docs，不會自行重構。
wayfinder
只給超過單一 上下文 window 的大型模糊工作。它解決 決策 tickets，不產生功能；路線清楚後才接 to-spec。
本機狀態：官方 README 現列的 22 個工程與生產力核心 技能 已全部存在於 Codex。`to-tickets` 唯一多出的舊句子也已移除，現在與官方 commit `ed37663` 完全一致；不需要重裝整套或改動 上游原版 前置中繼資料。
06 · 深層模組思維
好架構不是檔案越多，而是介面越小、內部能力越深
AI 維護 程式庫 時，最怕為了理解一個行為在許多薄檔案間跳轉。深模組把複雜性藏在小介面後面，讓修改、測試與知識集中在同一個地方。
淺層模組
介面接近實作一樣複雜，呼叫者必須知道太多細節。
大型介面：很多方法、參數與順序規則
薄實作：多半只是轉接或傳遞
深層模組
用小介面提供大量行為，複雜性、測試與修正集中在模組內。
小介面：少量清楚操作
深實作：規則、錯誤處理、資料轉換與依賴細節都藏在裡面
效益放大＋局部性
效益放大＋局部性
刪除測試
想像刪掉這個模組。如果複雜性散回許多 呼叫端，它有隱藏真正複雜度；如果程式反而更簡單，它可能只是 中間轉接層。
介面＝測試範圍
呼叫端 與測試應跨越同一個 模組邊界。需要繞過介面才能測試，通常代表模組形狀不對。
單一轉接器仍屬假設
只有一個 轉接器 時，不要急著建立抽象 模組邊界；真的有兩個變體，這條 模組邊界 才有實際價值。
07 · 本機符合性稽核
你的本機核心邏輯有對齊，但「會不會真的觸發」是另一件事
我把 啟用中 Codex 技能 與 GitHub 即時版本 原始檔逐檔比較，也檢查全域 路由 規則與現有 啟動紀錄。結果不能只用一個「有裝」或「沒裝」回答。
22 / 22
官方核心技能組合已安裝
| 檢查項目 | 本機狀態 | 與 Matt 現行版比較 | 判斷 |
|---|---|---|---|
| 使用中的 `grill-me` 包裝層 | 手動入口，轉呼叫 `/grilling`。 | 逐字 一致。 | 符合 |
| 使用中的 `grilling` 基本能力 | 一次一題、建議答案、查事實、確認前不動工。 | 逐字 一致。 | 符合 |
| 使用中的 `grill-with-docs` | `grilling + domain-modeling`。 | 逐字 一致。 | 符合 |
| Codex 全域路由 | Codebase 用 docs 版；一般想法用 grill-me；實作有 關卡。 | 比 上游原版 多一層 Michael 專用治理。 | 合理 |
| 自然語句自動觸發 | 包裝入口 設為 `disable-model-invocation: true`。 | 這是 Matt 的設計：包裝入口 要人手動叫；共用 基礎流程 才可由模型使用。 | 未保證 |
| 繁體中文穩定度 | 技能 本體沒有同語言規則。 | 上游原版 也沒有；應由 本機補充層 補。 | 需補強 |
| 呼叫證據 | 目前 紀錄 只有相關教學檔交付，沒有直接 grill 執行紀錄。 | 上游原版 不負責 Michael 的本機可觀測性。 | 無法證明 |
| Hermes 儲存庫副本 | 停在 2026-05-20，兩個核心檔案與 GitHub 即時版本 不同。 | 可能在 同步 時覆蓋 啟用中 新版。 | 同步風險 |
08 · 差異與決策
真正的差異不在 提示詞，而在觸發、語言與治理
不需要再安裝一份 Matt 技能。現在應把力氣放在「正確階段才啟動、能否證明啟動、同步時不覆蓋本機治理規則」三件事。
小型、可組合
手動 包裝入口 與模型可重用 基礎流程 分離。使用者記得何時叫 包裝入口；技能 本體保持最小。
優點：少 上下文負載、單一真實來源、容易組合。
增加治理分流
全域 `AGENTS.md` 已讓 程式庫 與非 程式庫 任務走不同入口，並加入常用中文口述別名與 實作關卡。
優點：符合 Michael 不希望 代理 亂做的使用習慣。
缺少可觀測閉環
仍缺直接 啟動紀錄 與固定 基本運作測試；舊 儲存庫副本 也可能成為錯誤同步來源。
風險：看起來有能力，實際何時觸發卻無法證明。
建議修改順序
先鎖定同步來源
先做
啟用中 Codex 技能 先維持 GitHub 即時版本 版；舊 Hermes 儲存庫副本 不得反向覆蓋，更新前先產生 diff 報告。
補 啟動紀錄 與 基本運作測試
先做
固定測四件事：一次一題、每題建議、可查事實不問人、確認前不實作。通過才算 健康。
本機補充層 補繁體中文
完成
已在全域 Codex 規則加入「問題、建議與文件跟隨使用者語言；Michael 預設繁體中文」，不改 上游原版 技能。
建立自然語句路由
完成
已加入 Grill Me、to tickets、程式碼 審核、除錯、架構健檢與 wayfinder 的繁體中文路由；仍保留官方手動／自動邊界。
保留目前小型架構
持續
不要把 spec、tickets、TDD、審核 全塞回 grill-me。各 技能 做完自己的工作就停止，避免重新變成大框架。
09 · 可直接使用
三種情境，使用三種入口
不需要背完整 技能 catalog。先判斷有沒有 程式庫、是否需要留下術語與決策，再選入口。
一般想法 / 非程式任務
/grill-me 請使用繁體中文。一次只問一個最重要的決策問題；每題附上你的建議答案與取捨。可從現有資料查到的事實請先查，不要問我。直到我明確確認 shared understanding 前，不要開始執行。
Codebase / 架構 / 領域設計
/grill-with-docs 請先讀取現有 CONTEXT.md、ADR 與程式碼，再用繁體中文逐題訪談。每題提供建議答案。確認的新術語即時更新 glossary；只有難以逆轉、令人意外且存在真實取捨的決策才提議 ADR。未經我確認，不要實作。
檢查 代理 是否真的照規則
請只做 Grill Me smoke test，不實作需求。 輸出並記錄： 1. 是否一次只問一題 2. 是否每題附建議與取捨 3. 是否先查可查的事實 4. 是否把真正決策留給我 5. 是否在我確認前停止執行 任何一項失敗，都要標記 fail 與原因。
10 · 來源／發布筆記
查證來源
技術結論以 Matt Pocock GitHub 即時版本 原始檔為準；不採用不穩定的星數與下載數作為能力證據。
- Gary Chen：Matt Pocock 技能 全拆解
- GitHub：mattpocock/skills
- ask-matt / 現行官方流程路由
- grill-me／SKILL.md
- grilling／SKILL.md
- grill-with-docs／SKILL.md
- domain-modeling／SKILL.md
- writing-great-skills／SKILL.md
- codebase-design／SKILL.md
- to-spec／SKILL.md
- to-tickets／SKILL.md
- tdd／SKILL.md
- code-review／SKILL.md
- diagnosing-bugs／SKILL.md
- implement／SKILL.md
- improve-codebase-architecture／SKILL.md
- wayfinder／SKILL.md
版本說明：本教材已由 Michael 確認，並以 Matt Pocock GitHub `main` 的 2026-07-21 commit `ed37663` 作為 技能 結構與觸發規則的核對基準。