ask-mattlisted

# 詢問 Matt 你不可能記得每個技能，所以開口問。 **flow（流程）** 是穿越技能的一條路徑。多數路徑沿著一條**主流程**行進，兩條**進入匝道**（on-ramp）匯入其中。其餘都是獨立技能，或是運行於其下的詞彙層。 ## 主流程：點子 → 交付 多數工作走的路徑。你有個點子，想要把它做出來。 1. **`/grill-with-docs`** — 透過訪談磨利點子。每當你在**工作目錄**中作業時就從這裡開始：它是有狀態的，會把學到的內容留在 `CONTEXT.md` 與 ADR 中。（沒有工作目錄？改用 `/grill-me`——見「獨立技能」。兩者都運行同一個 `/grilling` 原語；`grill-with-docs` 是會留下紙本痕跡的那個，因此只要有 repo 可以留存，它就是兩者中較好的一個。） 2. **分支——你能否在對話中解決所有問題？** 如果某個問題需要可執行的答案（狀態、商業邏輯、你必須親眼看到的 UI），繞道原型，由 **`/handoff`** 在兩個方向上搭橋（原型住在自己的目錄裡，這正是 `/handoff` 的用途——見「階段邊界」）： - **`/handoff`** 出去，然後針對那個檔案開啟新的 session， - 用 **`/prototype`** 以一次性程式碼回答問題， - 把學到的內容 **`/handoff`** 回來，並在原始點子討論串中引用它。 3. **分支——這是跨越多個 session 的建置嗎？** - **是** → **`/to-spec`**（把討論串轉成規格說明），然後用 **`/to-tickets`** 把它拆成曳光彈 ticket，每個 ticket 都宣告自己的**阻塞邊**。在本機追蹤器上，這表示每個 ticket 一個檔案，放在 `.scratch/<feature>/issues/` 下，以人工方式優先處理阻塞者已完成的 ticket；在真正的追蹤器上，這些邊會變成原生的阻塞連結，因此任何阻塞項已完成的 ticket 都可以被認領——逐個 ticket 啟動 **`/implement`**，並在每個 ticket 之間 **`/clear`** 上下文。每個 ticket 都是自足的，所以最後一個的上下文可以直接丟棄。 - **否** → 直接在**同一個上下文視窗**中執行 **`/implement`**。 不管哪條路，**`/implement`** 透過在內部驅動 **`/tdd`** 來建置每個 issue——一次一個紅-綠切片——然後在 commit 之前，以 **`/code-review`** 收尾，這是針對 diff 的雙軸審查（規範 + 規格）。當你只想在沒有完整規格說明的情況下以測試先行的方式建置某個具體行為時，就單獨使用 **`/tdd`**；每當你想針對固定基點審查某個分支或 PR 時，就單獨使用 **`/code-review`**。 ### 上下文衛生 把步驟 1–3 保持在**一個不間斷的上下文視窗**中——在 `/to-tickets` 完成之前不要 compact 或 clear——讓 grilling、規格說明與 ticket 都建立在同一份思考上。之後每次 `/implement` 才從 ticket 出發、重新開始。 這個做法的上限是**[智慧區](https://www.aihero.dev/ai-coding-dictionary/smar