！ 本篇文章將會介紹進階工作流：to-spec、to-tickets、wayfinder、triage 到 implement，把一個想法加工成一排 tracer-bullet tickets 然後全部做完 :D

TL;DR: https://dev.benben.me/slides/s/ironman-27-mp-skills-pro

本篇目標

讀完這篇你會學到：

• 用 /to-spec、/to-tickets 把對話變成規格與票
• 用 /wayfinder 處理「大到一個 session 裝不下」的工作
• 用 /implement 把 tickets 轉成通過審查的 commits

昨天 vs 今天：從「單次對話」到「跨 session 工作流」

Day 26 的基本盤解決「一次做好一件事」。今天這組 skills 解決更大的問題：

工作大到一個 agent session 裝不下、大到需要 issue tracker、大到中途會換人換模型——怎麼不亂？

答案是經典的：拆解成文件，讓文件當記憶體。

第一步：/to-spec——把對話結晶成規格

你剛跟 AI 聊完一輪 grill（Day 26），共識都在對話裡。/to-spec 做的事：

• 把現有對話合成一份 spec（不再重新面試你）
• 發佈到 issue tracker（GitHub / Linear / 本地檔案，setup 時選的）

關鍵字是「synthesize」——它不問新問題，只整理已經談定的。談都談過了，規格只是把共識固化下來。

第二步：/to-tickets——把 spec 切成 tracer bullets

spec 是「要什麼」，tickets 是「按什麼順序做」。/to-tickets 把 spec（或任何計畫、甚至一場對話）拆成一組 tracer-bullet tickets：

• 每張 ticket 是一個可獨立完成的工作單元
• 每張 ticket 宣告自己的 blocking edges（被誰擋、擋誰）——本地檔案模式寫成文字，真 tracker 上是原生 blocking links
• 「tracer bullet」的意象：先打一發曳光彈穿過整個系統（端到端的最小縱切），再加厚——不是把一整塊模組做完再做下一塊

依賴關係明示之後，「哪張票可以先開工」一目瞭然——這正是 Day 28 多 agent 並行時的排程依據。

遇到迷霧：/wayfinder

有些工作不是「多難做」是「不知道怎麼做」——路線本身就是未知數（大重構、新架構導入）。/wayfinder 的策略：

1. 把迷霧拆成一張張 decision tickets 放上 tracker
2. 一次解決一張——每張票就是「在岔路口選邊站」
3. 全部解完，到終點的路就清了

跟 to-tickets 的差別：to-tickets 假設路已知、切執行單元；wayfinder 承認路未知、先買地圖。

入口整理：/triage

tickets 一多就需要 分類 守門員。/triage 用一個 角色狀態機 把 issue（外部進來的 bug report、feature request）逐步分類、必要時 grill 原作者，最後寫成「agent-ready brief」——一張 AI 拿了就能開工的任務說明。雜亂的 backlog 經過 triage，變成乾淨的燃料庫。

執行端：/implement

前面都在備料，/implement 開工：

• 讀 spec 或一組 tickets
• 在事先約定的 seam 上驅動 /tdd（Day 26 的紅綠循環）
• 做完自動跑 /code-review（雙軸審查）
• 審查過了才 commit，然後下一張票

注意它的工作方式：不是「一口氣全做完」，而是 每張票走完 tdd → review → commit 的完整小循環。做完的定義不是「code 寫了」，是「審查通過且 commit 了」。

完整管線一覽

想法
 └→ /grill-me            對齊（Day 26）
     └→ /to-spec          結晶成規格
         └→ /to-tickets   切成帶依賴的票
             ├→ /wayfinder  （路線迷霧時插入）
             └→ /implement   逐票：tdd → code-review → commit
                 └→ /triage   （外部 issue 進來時的入口）

這條管線跟 Day 23 的 OpenSpec 哲學相通（需求進 repo、不進 chat history），差在 OpenSpec 是 跨工具的格式與歸檔系統，這條管線是 單團隊的加工流水線 ——兩者可以混搭：OpenSpec 管 spec 的存放與演進，mp skills 管加工的動作，這個就是整套 skill workflow 厲害的地方，當中的每個步驟都可以自己客製化，兼容成自己的工作流。

常見問題

Q：一定要照順序跑滿整條管線嗎？
A：不用。小任務 grill 完直接 implement；只有「大且迷」的工作才需要全套。管線是工具箱，不是捷運站。

Q：to-tickets 產的票跟我自己寫的票有差嗎？
A：最大差異是 blocking edges 被當成一等公民。人寫的票常漏依賴，多 agent 並行時就互相卡死——這個細節在 Day 28 會變成主角。

Q：wayfinder 的 decision tickets 誰來解？
A：你跟 agent 一起——每張決策票本質是一次小型 grill。AI 給選項與後果分析，你拍板。決策權不外包。

小結

• /to-spec 合成對話成規格；/to-tickets 切成帶依賴的 tracer-bullet tickets
• /wayfinder 用 decision tickets 清迷霧；/triage 是 backlog 守門員
• /implement 逐票走 tdd → code-review → commit 的小循環
• 管線可與 OpenSpec 混搭：格式歸 OpenSpec，動作歸 skills

明日預告

Day 28：herdr——coding agent 的終端機多工 runtime，多張票、多個 agent、多個專案，同時開工不失控。

有任何疑問但沒有 iT 邦幫忙帳號，或是想匿名提問？
歡迎到 https://dev.benben.me/q/P3C5U6 提問或加油打氣，沒意外的話會在完賽之後一起回答 :D