Ship with skills, not vibes 把 25 支 skill 串成一條開發流程

它寫的是回答一個問題的丟棄式程式碼。問題先來，而且決定後面所有東西的形狀；回答錯問題的 prototype 是純浪費，不管它多好看。「丟棄式」是對怎麼寫的約束，不是「一定要銷毀」的承諾：沒有測試、除了跑得起來以外沒有錯誤處理、沒有抽象、沒有持久化。

兩條分支的產出物差很多。「這個邏輯或狀態模型感覺對嗎？」得到一個可分享的單一 HTML 檔——自帶 state panel、free-play 按鈕、分頁式導覽，全部用領域語言標示，可以直接丟給設計師或領域專家自己感覺；背後邏輯是一個乾淨的純模組，不碰 DOM，驗證過就能抬進正式程式碼。「這個看起來該長怎樣？」得到同一 route 上幾個差異劇烈的 UI 變體，用浮動底列切換；變體必須在結構上不同意，不是顏色——三個微調過的 card grid 是壁紙不是 prototype。

發現自己在「加固」它的那一刻，你就不是在做 prototype 了——加測試、接真資料庫、為了「以後可能要」而泛化。

產出物怎麼處置：答案（裁決加它解決的問題）落在耐久的地方——commit message、ADR、實作 issue；prototype 本身不刪，但也不進 main，commit 到 prototype/<name> branch、永不 merge，在實作 issue 上留一個指標。

坑：agent 會在你其實該實作的時候叫你 prototype——命名問題，它對不熟流程的 agent 讀起來像「有票之後的顯然下一步」。另外不要 prototype 整個 app：沒有自然停止點，會靠慣性變成正式產品，而「沒測試沒錯誤處理」的程式就這樣上線見用戶。

它只從一手來源工作（官方文件、原始碼、規格、第一方 API），每個主張都追回擁有答案的那個來源。它不在對話裡回答你——輸出是一份檔案，每個主張帶連結。決定性的動作是：讀的部分跑在背景 agent。

research 是你委派的跑腿，不是你外包的思考。

坑：它會生出第二個自己（issue 530）——skill 叫呼叫者開背景 agent 但沒限制 agent 類型，於是生出的是通用 agent、握著同樣的工具和指令、再開一次。有人量到單一 research 任務跨三次重疊執行燒掉約 450k token，重複那個在半小時後、完全在視線外完成。呼叫後看一下背景任務列表，把重複的停掉。

另外三件：反向失敗是你的全域指令禁止再委派時，背景 agent 會禮貌拒絕、skill 靜靜什麼都沒做；「高信任來源」由模型自己判斷、沒有 allowlist，你實際的緩解手段是隨機追兩三個引用，落在「那個東西的摘要」而不是那個東西本身就是失敗；沒有停止準則，範圍是你的責任——一個 API、一個行為、一個版本主張，比「research X」回來得好太多。

research 檔案不是 ADR：ADR 留、research 檔用完歸檔或刪掉。過期的 research 檔比沒有更糟，它會污染未來的 repo 讀取。

六階段：建 repro、最小化、排序假設、埋探針、帶回歸測試修好、清乾淨。

它不讓 agent 在有「緊」的回饋迴圈之前形成理論。一個具名指令、已經跑過一次、在這個 bug 上是紅的、修好之後會變綠。coding agent 拿到 bug 報告的預設行為是讀程式碼然後猜——這支 skill 擋掉它。沒有能變紅的指令，就沒有 Phase 2。那道 gate 就是這支 skill 的全部價值。

「有一個」迴圈不是目標，「緊」才是：快（秒級）、決定性（每次同樣裁決）、銳利（斷言你確切的症狀，不是「沒 crash」）、agent 能無人看管地跑。30 秒又會 flaky 的迴圈，比沒有好不了多少。對偶發性 bug，目標不是乾淨的 repro 而是提高重現率——迴圈觸發、平行化、加壓、注入 sleep。

它拒絕把衝突當成文字問題。動一個 hunk 之前，先把兩邊追回一手來源——commit message、PR、原始 issue——所以它是在兩個意圖之間選，不是在兩塊文字之間選，並且在相容的地方兩邊都保留。真的不相容時，選符合這次 merge 已陳述目標的那邊，並講出取捨。它不會為了粉飾衝突而發明新行為，而且它不放棄：merge 一定被帶到一個完成的 commit。

它還會找出 repo 自己的自動化檢查並在 commit 前跑——因為 merge 是 git 裡最容易產生「同時滿足兩個 branch、但兩邊測試都不過」的地方。

額外的實務知識：不要為了避免衝突而在平行任務之間「劃分檔案」，那成本比收益高。唯一值得保留的紀律是大重構先做。worktree 平行開發時，merge 回去最好由寫那個改動的 session 做，因為只有它知道意圖。把大家的衝突 batch 給最後一個 agent，正好丟掉這支 skill 要辛苦重建的東西。

它掃 codebase 找加深機會——淺模組（介面幾乎和它藏的東西一樣複雜）可以變成深模組的地方——寫成一份 HTML 報告，然後對你選的候選做 grilling。

它從不改程式碼。整個 run 產出「一個 HTML 檔加一場對話」。重構本身之後在另一個 session、走正常建置流程。這就是它是巡檢而不是重構工具的意思，也是為什麼值得對「你還沒準備要動」的 codebase 跑它。

兩道過濾器：deletion test——想像刪掉這個模組，複雜度會集中到一個更小的介面後面，還是散開到各個呼叫者身上？只有「集中」的案例拿到卡片。另外除非你指定區域，它先讀最近的 commit 歷史，把掃描偏向正在變動的路徑——沒人碰的程式碼裡的加深，是你永遠不會兌現的重構。

強度標章三階：Strong（deletion test 清楚通過、摩擦真實，認真看）、Worth exploring（說得通，但報酬取決於程式碼接下來要去哪）、Speculative（為完整性列出，大部分可以安心忽略）。

只用於你沒有建立的 issue。原始 bug 報告、外來 feature request、突然出現的外部 PR。to-tickets 產出的票依構造就已經 agent-ready，對它們跑 triage 最好的情況是白做工。它建議然後等待：告訴你分類與狀態的判斷加理由，在你指示之前不套用任何東西。

每個被 triage 的項目最後帶恰好一個分類角色加一個狀態角色。分類兩個：bug、enhancement。狀態五個：needs-triage（你需要評估它）、needs-info（等回報者，回覆後回到 needs-triage）、ready-for-agent（完整規格化、附 agent brief）、ready-for-human（同樣的 brief 加上「為什麼不能委派」）、wontfix（關閉，理由已記錄）。

wontfix 分三種，差別重要，因為只有一種會寫進知識庫：已實作的留個指向它已存在位置的留言、不寫進 out-of-scope（那是已建功能不是被拒功能，寫進去會污染去重檢查）；拒絕的 bug 禮貌解釋後關閉；拒絕的 enhancement 在 out-of-scope 目錄寫一份檔案、從關閉留言連過去。那個目錄是一個被拒概念一份 markdown（不是一個 issue 一份），而 triage 在評估任何東西之前先讀整個目錄，按概念比對而非關鍵字。

先驗證再寫 brief：對 bug 照回報者的步驟重現，對 PR checkout 並跑相關測試，然後報告三種結果之一——已確認（附程式碼路徑）、無法重現、細節不足以嘗試（這本身就是最強的 needs-info 訊號）。這一切都是為了讓 agent brief 變好，而它被寫成耐久而非精確：寫型別、簽章、行為契約，永不寫檔案路徑與行號，因為 issue 可能躺好幾週而底下程式碼在動。

坑：label 不會自動建立；五個狀態不夠用是最常被提的缺口（blocked、deferred、implemented 都有人要，都沒 ship）；不要一次對整個 backlog 放它跑——「顯示需要注意的東西」那一 pass 是給挑選用的便宜列表，一次跑二十個 issue 時 agent 會悄悄把它當成證據基礎，而它只回 issue 內文、不回留言。

它接手一個大到一個 agent session 裝不下的工程——你能講出目的地、但還看不見路線——把它畫成 tracker 上一張共享的地圖，由 decision ticket 組成，然後一次解一張直到路清楚。

它規劃、不執行。每張票握著一個「解決後產出決定」的問題，而不是一塊要執行的建置切片。地圖完成的定義是：在有人去建這個東西之前，沒有東西還需要被決定。這條規則是 agent 最常打破的。

與 grill-with-docs 的分界是 session 數，不是專案大小：一個對話裝得下就用 grilling（更便宜也更好）；裝不下才用 wayfinder。對一個範圍良好的功能抓 wayfinder 是常見錯誤。

地圖上的四樣東西：Destination——走到盡頭是什麼樣子，在任何票存在之前先命名；Decisions so far——每張關閉的票一行，各自連到細節真正住的地方；Not yet specified，也就是戰爭迷霧——你看得出要來、但還無法精確表述的決定，判準是你現在能不能精確說出那個問題，不是你能不能回答它；Out of scope——判定在目的地之外的工作，關掉、永不畢業。地圖是索引不是儲存，決定只活在它自己的票裡。

Frontier 是「開著、沒被阻塞、沒被認領」的票。session 在做任何工作之前先把票 assign 給自己來認領，所以 assignee 就是認領。票全程用名字稱呼，不用裸的編號——一牆的 issue 編號在敘述裡沒法讀。

它把當前對話壓成一份交接文件——一個 markdown 檔，寫到 OS 暫存目錄（不是工作區），讓一個全新 agent 讀了就能接手。

它買的是可攜性，不是壓縮。這讓它比聽起來窄得多：只有工作要移動時你才需要檔案。四個觸發情境：換 harness、搬到不同目錄或 repo、把工作送給同事、把 phase 中途發現的支線分叉出去。

最常被跳過的用法是分叉。你留在自己的 session，把累積的 context 複製一份交給第二個 agent 平行工作。prototype 岔路就是這樣用的：你正在一場很深的設計對話裡、撞到一個只有跑起來才能解的問題、又不想把辛苦建起來的 thread 花在查這件事上——handoff 到一個 prototype session、拿到答案、把答案交回來、在原 thread 引用它。兩次跨越、一場活著的對話、什麼都不用重講。

什麼會旅行：文件帶著活的 thread（在飛什麼、為什麼、下一步），加上一段建議的 skill。秘密會在寫入前被遮蔽。它刻意不帶任何已經寫下來的東西——spec、計畫、ADR、issue、commit、diff 一律用路徑或 URL 引用、絕不複製。

坑：檔案在暫存目錄，路徑長、每個 OS 不同，問它路徑並記下來再往下走；有些環境會在 session 之間清掉 temp，下一個 session 不會很快開始就自己複製到耐久的地方；交給下一個 agent 的方式是指向路徑，不要把摘要貼進 shell 指令——含特殊字元的摘要會被搞爛，而典型失敗是靜默截斷；「它抓到 what、沒抓到 why」是公允的批評，把「下一個 session 要做什麼」當參數傳進去，並留意它把沒驗證過的信念寫成事實。

它把一個你無法自己拍板的決策，變成一份問卷，交給那個握有你缺的東西的人。

它烤的是「這次寄送」，不是主題。針對主題訪談你在這裡毫無意義——不懂主題正是你要寫給別人的原因。所以它只問你永遠答得出的兩件事：要給誰（他們的角色、專業、跟你的關係，這固定了語氣與文件要自帶多少 context）與你需要拿回什麼（你無法自己解決的具體決定或事實，這變成成品被衡量的檢查表）。之後全是起草。

文件的形狀：一行 purpose 加一小段給「從沒在你腦子裡待過的人」的 context；問題最重要的先來、依主題分組；一題一個想法、絕不複合；明確允許回答「我不知道」——被標記的不確定有用，讀起來像事實的自信猜測沒用；結尾一個 catch-all。

它刻意不分支、不多收件人。三個人握著三塊答案，就跑三次。最常見的用法是一場 grilling 卡住了：在同一個對話裡跑它——它沒有 ingest 階段，能在 grilling 之後 work 純粹因為那場 session 已經在 context 裡。

agent 會把剛講的東西重新推銷一次：補上你缺的 context、用白話寫、並使用你專案 CONTEXT.md 裡的詞彙。

這支 skill 只有三行，那是設計不是未完成稿。打冗長的 skill 會靠變長而失敗：一份四百行的「簡潔 skill」還是會讓模型冗長，因為模型讀到的是體積而不是懇求。

名字就是機制。帶頭的詞是 wait。「講精簡一點」是關於 agent 輸出的指令，模型會用「剪字」來服從，於是你更迷路。wait 是關於你的狀態：它說「理解在這裡失敗了」。聽到「講短一點」的 agent 寫電報；聽到「等等，你把我弄丟了」的 agent 會退回去重講。每個流行的解法都在命名輸出，模型於是過度修正成一種更短但沒更清楚的語體；命名聽者同時要到兩半：更少的字，而且你缺的那個前提。

它也刻意說「重講那個」而不是「上一則訊息」——把你弄丟的通常比一段大，多遠要退回去由 agent 決定。真正的解藥是事先建立共享語言；wait-what 修的是已經發生的那一則。

它把你執行它的那個目錄變成常設教學工作區，用一系列自帶樣式的短 HTML 課程跨多個 session 教你一個主題。

它不從模型已知的東西教。parametric knowledge 被當成不可信：教之前它先去找高信任資源、記進資源檔、並在每一課裡引用。它是有狀態的——mission、資源、課程、學習紀錄全部以檔案形式住在目錄裡：

核心觀念是 storage strength（長期保留）而不是 fluency（當下的回想感，讀的時候像精通、一週後就沒了）。它用期望難度建前者。知識先來（此時難度是敵人，會吃掉你理解所需的工作記憶），技能再靠緊的回饋迴圈操練（此時難度是工具）。課程很少被重讀，參考文件會——所以一課的壓縮精華屬於參考目錄，不是埋在引入它的那一課裡。

坑：檔案可能被寫到錯的地方（issue 377，有人的課程被寫進全域 skill 目錄），開始時明確講出目錄名；小考正確答案永遠是第一個選項（多模型確認、未修，有貢獻者測到 9 課 33 次全部落在 A）；沒有能力評估步驟，第一則訊息就把你的既有知識與缺口講出來；沒有間隔重複排程，要複習就自己要。

不只給程式用——紀錄裡非程式的用途佔更大部分。在程式裡，最強的用途不是從零學一門語言，而是在陌生的 codebase 或新團隊的技術棧裡找方向。作者提過一個漂亮的組合：被烤到一個你不懂的東西時，不要停下 grilling 去學——handoff 到一個教學工作區、在那裡學會、再回來接續。

它產生一支互動 bash script，一步一步帶人類走過手動程序——串第三方服務、跑一次性遷移、把專案從狀態 A 搬到狀態 B。

agent 寫 script，但從不執行它。你在自己機器上跑。所以 wizard 不是一份你照著做的說明——它是一個驅動流程並持有狀態的程式，你的部分是點、貼、按 Enter。Stage 是「一個畫面上的一件聚焦任務」，script 在 stage 之間清空終端。

寫 script 之前先 scoping：它讀你的 repo 而不是冷問——環境檔、compose 檔、framework config、以及 CI 設定裡每一個 secret 與變數引用；每一個都是 wizard 必須產出的值。然後把排序過的 stage 清單給你確認，之後才把每個 stage 對應到人類走的確切路徑。不知道現在的 UI 長怎樣時，它問你或查文件，而不是發明點擊。

template 已經解決了 UX：進度、確認門、跨平台開 URL、secret 隱藏輸入、環境檔冪等寫入、CI secret 寫入、以及「它必須跳過什麼」的收尾摘要。固定函式庫那半每支 wizard 都一樣、永不手改，一致性就是重點。寫 wizard 的 agent 不會端到端跑它，改用靜態驗證，第一次跑是你，而那次就是測試。

坑：不能中途回上一步，第 3 站打錯就中斷重跑（重跑很便宜，已寫進環境檔的值會當預設回饋）；提示裡方向鍵有 bug（issue 741），backspace 有效；它不會去查第三方服務的狀態；API key 不會進模型 context——但你在 scoping 時把 key 貼進聊天，那就跟任何貼上的文字一樣在 context 裡了。

它在你設計的同時建立與磨利專案的 ubiquitous language——挑戰和詞彙表衝突的用詞、在你用了模糊字時逼出精確的字、用具體情境壓力測試一段關係直到邊界精確。

它是主動紀律、不是被動的。讀 CONTEXT.md 借用詞彙是任何 skill 都能做的一行習慣；這支是給你在改變模型的時候用的。這就是它會打斷你的原因：它在術語被解決的那一刻、對話中間就寫進 CONTEXT.md——因為批次版是一場 session 的摘要，即時版是那場 session 的實際產出。

兩個產物、兩套標準。CONTEXT.md 裝術語（一個東西是什麼，一兩句話），寫入門檻是「一個模糊的詞變成正式術語」，時機是即時，永不裝實作細節、spec、草稿紙、一般程式概念。ADR 裝一個決定（一到三句：context、選擇、理由），寫入門檻是三個全中——難以逆轉、沒有 context 會覺得意外、真實取捨的結果——而且是提議，不預設。

要真正記住的是 CONTEXT.md 那條規則，因為它是實戰中會壞的那條：它是詞彙表，而且只是詞彙表。不管的話，模型會把「寫進 CONTEXT.md」當成「把你給的每個答案都持久化」的許可，檔案就變成一份跑動的 spec——這是本 skill 最常被回報的問題，跨多個模型。

讓這支有感的動作：你陳述某件事怎麼運作時，它去查程式碼並把矛盾攤出來——「你的程式碼取消整張 Order，但你剛說可以部分取消，哪個對？」語言和程式碼被迫出聲對齊，在任何一邊被改之前。限制：它只交叉參照程式碼與已 commit 的文件，不搜你的 issue tracker，所以幾個月前在一張已關閉 issue 裡吵完並刻意定案的命名衝突，會被當成新的攤出來。

坑：CONTEXT.md 長到 500 行以上——大小是症狀不是病，直接下令它精簡並移除實作細節；只有在檔案真的精瘦、卻仍涵蓋兩個讀者不會想同時裝進腦裡的領域時，才考慮切分——切一個臃腫的檔案只會得到好幾個臃腫的檔案。自動觸發是它最弱的地方：一場 grilling 跑完 CONTEXT.md 一動也沒動，就是這件事發生了，點名叫它。沒有經人審閱、由 agent 撰寫的詞彙表比沒有更糟：它會變成聽起來很自信的傳說，被後續 session 當成真理。

skill、指令檔、spec、runtime prompt、README——任何 agent 會讀的文件。包裝不同，寫法一樣。

它的預設動作是刪除，不是解釋。叫 agent 寫給另一個 agent 的指令，它大部分字會花在解釋模型已經知道的東西，每一行都是 no-op：付了 context 卻沒改變任何行為。這份參考就是找出它們的鏡片，所以它在你已經有的文件上賺到的價值，至少和在空白檔案上一樣多。

兩種負擔。Context load 是永遠載入的材料在 agent 窗口上的成本：指令檔的一行、skill description、任何每個 turn 都在 context 裡的東西，不管它有沒有被觸發。Cognitive load 是在你身上的成本：有哪些文件存在、什麼時候該抓哪一個，你就是那個索引。這不是要最小化的成本，它是人類主導權的價格。想通這兩種之後，大部分寫作決定都變成同一個取捨在不同地方做。

五個槓桿：Context pointer（在 context 裡、指名 context 外材料、並編碼「何時去拿它」的引用；決定 agent 多可靠地伸手穿過它的是 pointer 的用字，不是它的目標）、Information hierarchy（從「檔內步驟」到「檔內參考」到「pointer 後的外掛參考」的梯子）、Completion criteria（對抗過早完成的防線）、Leading words（模型預訓練裡已有的壓縮概念，錨定兩次：body 裡錨定執行、pointer 裡錨定觸發）、Pruning（單一真實來源、相關性、逐句套用 no-op test）。

no-op test 是行為性的、不是美學性的：刪掉那一行，問 agent 的行為有沒有改變。一個句子不通過，刪整句而不是修字。對它有歧見時，跑那份文件來解決，不要爭論。判準：文件變好的同時變短，而且你會驚訝剩下這麼少；沒有任何東西被說兩次（重複是「這份文件從未被測過」最可靠的徵兆）。

它拿一個鬆散的想法訪談你，直到你能對它做出承諾。你不需要一份想好的計畫才能開始——產出那份計畫正是這場 session 的用途。它是無狀態的：不寫檔案、不留工作區，留下的只有你腦子裡那個更銳利的版本。主題不必是程式，也不需要 repo。

關掉 plan mode。它會催 agent 趕快產出計畫，那正好和「保持在提問狀態」相反。

它在正常工作的樣子：你不同意某件事——一場你完全沒推回去的 session，是一場你不需要的 session；問題以「少數幾輪」而不是一長串點滴到達，而且後面的輪次明顯建立在你前面說的話上；你走到一個沒預期的地方，因為某個問題翻出了你一直在隱性做的決定；結束時，每個選擇你都能對一個當時不在場的人辯護。

數輪不要數題。46 題分 4 輪是普通的一場。200 題代表範圍太大，而且超長 session 會漂進 dumb zone——context window 滿到問題品質下降。烤完之後如果確定要做，不要開新 session，那場對話的 context 就是價值所在。

它建議然後停下。不會 grill、不會寫 spec、不會開檔案、不會幫你發射它剛點名的 skill——你拿到的是「下一步該打什麼」，然後你去打。它給你的思考單位是 flow：一條穿過 skill 的路徑，而不是單一個 skill。

必須知道的誠實限制。它是手寫的地圖、會落後 repo，而且只認得這個 pack 的 skill。它會告訴你「一半的 skill 沒安裝」——已知未修：大部分被它路由的 skill 是 user-invoked，harness 就不把它們放進注入 agent 的清單，agent 把那份清單當成完整的，於是報告它們不存在。它們有裝。

它也可能描述錯別的 skill 的行為：它從自己那份一行摘要回答，而不是從 skill 本身。有一份詳細回報在單一 session 裡追到三次，包括憑「把 thread 變成 spec」這個粗略印象建議跳過 to-spec——那份 SKILL.md 從未被打開，代價是少了一次真正的 seam 檢查，切出來的票低估了工作量。當它對別的 skill 做出承重的斷言時，要它先去打開那份 SKILL.md。

定位：ask-matt 是這整套之上的 secondary source。router 和 SKILL.md 打架時，SKILL.md 是對的。

處境：客戶回報「有時候按送出會噴 500」，你自己重現不出來。

1. 這是別人回報的，先走匝道：/triage。能不能照回報者步驟重現？重現不出來就 needs-info，或決定現在就追。
2. 決定現在追，開新 session：/diagnosing-bugs，並明講「先幫我建一個會變紅的迴圈」。

後面是機械性的：最小化（剩下的每個元素都要能說出為什麼是承重的）、3 到 5 個排序過可否證的假設（唯一的人類檢查點）、埋帶標籤的探針、先寫回歸測試再修、清乾淨、猜對的假設寫進 commit message。

一個分岔要知道：沒有正確的 seam 可以放那個回歸測試時，它應該直說，而不是寫一個給你假安全感的淺測試——「沒有 seam」本身就是發現，交給 improve-codebase-architecture。

處境：你剛加入一個八年的專案，或接手一個 vibe-coded 的 repo。沒有 ADR、沒有領域語言、沒有設計原則。

1. 第一天：/setup-matt-pocock-skills 設定 tracker 與文件配置。
2. 第一天：/grill-with-docs，請它幫你把這個既有 repo 用 CONTEXT.md 建立起來。預期一場很長的訪問（有人回報 50 題以上才把檔案弄成形），而且要主動導引——它會讀程式碼、問你它找到什麼，而「程式碼裡現有的哪些詞才是對的詞」是你決定的。
3. 第二天：/improve-codebase-architecture，開口就說「不要烤我，先給我報告」。全部都是 Speculative 等於它其實什麼都沒找到；挑一個 Strong 的候選。
4. 第二天：一次一個候選，讓它對那個候選 grilling，產出是「決定」不是 diff。然後接 to-spec、to-tickets、implement。
5. 之後：每幾天再跑一次架構巡檢當保養。

誠實的期望值：真正失控的專案，有人回報它「幫了一點但還是不夠」；一個八年的 legacy codebase 上有人看到模型在原地繞圈，而同一支 skill 在整齊的 repo 上會產出乾淨的圖。目前沒有專門處理這種案例的 skill。

處境：要從零做一個新產品模組，路線完全不清楚，明顯不是一場對話能談完的。

1. 先確定五個 wayfinder: label 存在（不存在的 label 會讓 gh 直接失敗）。
2. /wayfinder。第一件事是命名 destination。它問的是「整張地圖的目的地」，不是這場 session 的目的地；把範圍縮到一個有界的 epic，不要「實作 V1」。
3. 它做一次廣度優先的 grilling，畫出 Destination、Decisions so far、迷霧與 Out of scope。迷霧與票的判準是你「現在」能不能精確說出那個問題。開場的 grill 找不到任何迷霧，它應該停下來說「這件事小到不用地圖」。
4. research 票在畫地圖時就被發射並行燒；其他票一次做一張，用 assign 給自己來認領。
5. 每解一張：貼 resolution 留言、關票、在地圖留一行，然後停下。清掉前方的迷霧，把現在可表述的畢業成新票。
6. 地圖清空後：/to-spec #<map_issue>（傳主地圖，不是個別 decision ticket），然後 /to-tickets、/implement。

三個致命坑已在 第 06 節 的 wayfinder 條目列出：agent 會開始寫正式程式碼、不要跳過 to-spec、不要平行跑 grilling 票。

處境：你在想一個商業決定——要不要做一條新產品線、一份提案怎麼定價、一篇文章的論證骨架。

1. 開一個乾淨對話（不需要在任何 repo 裡），關掉 plan mode，跑 /grill-me。
2. 一輪一輪回答，用編號整批回。推回問得太淺的問題；範圍在漂就講；「我不知道」是真的答案。
3. 遇到「看到東西才能答」的問題，它是 ungrillable。非程式情境下通常是：先做一頁草稿、先算一張表、先問一個客戶。
4. 遇到「答案在別人腦子裡」的問題，在同一個對話裡跑 /to-questionnaire，寄給那個人，答案回來再開下一輪。
5. 它是無狀態的：不寫檔案、不留工作區。留下的只有你腦子裡那個更銳利的版本。