【Day - 14】談到，我希望把 discussion 留下來，讓下次能接著談。不過，紀錄裡的決定與原因，還是得靠前面的討論慢慢釐清。這篇就來看看幾種討論方式，怎麼準備背景、安排提問，以及最後會留下什麼結果。
Spec Kit 的 clarify、OpenSpec 的 explore、Spectra 的 discuss，以及 Superpowers brainstorming，都可以協助討論，但它們各自想解決什麼問題，又有什麼不同呢？
Matt Pocock 的 grill-me 則是我後來才接觸到的啟發，這裡也一起比較。我沒有實際安裝或執行過他的 Skills，對 grill-me 的理解來自 AI 協助翻譯與說明、他人的介紹，以及後來查閱官方文件，所以這部分會以文件為準。後續再說它怎麼影響我自己的 discuss。
那麼，我們就從最早使用的 Spec Kit clarify 開始，看看它怎麼找出規格裡還沒說清楚的地方吧！
Spec Kit clarify 一定要從已經存在的 spec.md 文件開始。接著，它會從功能範圍、資料、操作流程、例外情況與成功條件等面向，找出規格裡還沒有寫清楚的地方。
【Day - 3】提過，我沒有保留當時安裝的精確版本，這裡以同時期的 0.0.79 官方文件作為流程參考。clarify 最多提出五個會影響實作或驗證的重要問題，而且一次只問一題。每次收到答案後，就會把結果補回原本的 spec.md，再繼續處理下一個缺口。
clarify 主要是把規格裡沒說清楚的地方補齊。至於程式要怎麼寫、要選哪種架構或技術，會留到 plan 再討論，不會在這一步主動查看 codebase、研究實作方式。
所以，clarify 想回答的是：
這份已經存在的 spec，還有哪些重要內容沒有說清楚？
如果手上還沒有 spec，只是有個想法想先聊聊，或遇到問題想查清楚，就可以使用 OpenSpec explore。它可以讀取 codebase、比較不同作法，幫我們釐清有哪些方向可以走。除了建立 change 以前，實作途中遇到問題時，也能回到 explore 繼續討論。
OpenSpec 1.0 的 explore 沒有規定一定要問幾題，或照著哪些步驟談到結論。需要查程式時就先查，需要比較方案時就一起比較。如果只是想弄懂一個問題，找到答案後就可以結束；如果談完決定要做，再把結論帶進後面的規格與設計，不必每次都留下一份文件。
所以，explore 比較像是在回答：
這個問題現在是什麼狀況，又有哪些方向可以繼續往下走？
Spectra discuss 則明確要求這場討論要有主題與目標，最後也要整理出結論。龍哥在 Spectra 2.0 的介紹中，把 discuss 的行為概括成：先讀相關 code、提出幾種方案，再透過提問慢慢收斂；即使目前資料不足，也要把缺少什麼說清楚。
不過，公開文章並沒有完整寫出 discuss 怎麼決定提問方式。所以，我直接查看 Spectra 2.3.1 的 spectra-discuss Skill，再回頭對照自己實際使用時遇到的情況，才看懂它是怎麼判斷的。
在真正開始提問前，Skill 會先準備這場討論需要的背景。它會用 spectra list --json 查看目前有哪些 changes；如果主題已經指定某個 change，也會先讀取裡面的 artifacts。
如果專案另外整理了共用詞彙，也會在這個階段一起帶進來。還記得【Day - 10】初始化圖裡，用虛線標出的 openspec/LANGUAGE.md 嗎？它不是初始化一定會產生的檔案，而是專案需要時才自行加入的共用詞彙表。如果這份檔案存在，discuss 就會先讀取裡面的慣用名稱與應該避免的說法；沒有的話，就直接略過這一步。
接著，AI 會從討論主題挑出 2～5 個關鍵字，搜尋相關程式碼，最多讀取五份檔案，文件與測試不算在內。找到三份以上相關程式檔案時，就先列出自己的理解，讓我們確認（Assumptions）；不足三份時，則一次問一題，把需要的資訊問清楚（Interview）。開始前，AI 也會說明這次用哪種方式，以及選擇的原因。
如果不習慣它選的問法，也可以直接要求切換。例如希望一次只回答一個問題，就請它改用 Interview；想先看看 AI 怎麼理解目前的情況，就請它列出 Assumptions。
Assumptions 模式會先提出 3～5 個暫定判斷，讓我們確認。每一項 Assumption 都要包含三個部分：
Approach 說的是「目前打算怎麼做」，Evidence 是「從哪些程式碼或資料得到這個判斷」，If wrong 則是「如果判斷錯了，哪些作法需要跟著改」。
列完後，AI 會先讓我們確認哪些地方理解錯了，再繼續追問需要修正的部分。
Interview 則是一次問一個問題。遇到需要選擇作法的地方，AI 會列出選項、各自的優缺點，以及自己的建議，再根據我們的回答繼續問。
如果討論牽涉到新增模組、前後端怎麼交換資料、資料需要經過好幾層處理，或資料怎麼保存，Skill 還會要求 AI 多確認：這段邏輯放在哪裡比較合適？資料是不是繞過太多層？每一層都有必要嗎，拿掉會影響什麼？Skill 把這項檢查叫做 interface depth check（介面深度檢查）。一般的文字、樣式或文件調整，就不需要問這些問題。
不管用哪種方式討論，最後都要排除不適合的作法、整理出建議，並說清楚為什麼這樣選，以及有哪些優缺點需要考慮。如果談到具體的功能行為，AI 會先舉例確認我們想的是不是同一件事，再整理最後的決定（Decision）、原因（Rationale），以及這項決定適合補進哪份規格或規劃文件（Capture to）。這裡保存的是討論後的結論，例如把新需求補進 spec、把設計決定補進 design，並不會另外留下整場 discussion 的過程。如果還無法決定，也要說明目前缺少哪些資訊，以及接下來需要確認什麼。
整段 discuss 可以讀 code、調查問題，也可以把結論整理進 artifacts，但不會直接開始修改程式碼。真的決定要實作後，才會提醒我們進入 propose。
現在有什麼不同？ Spectra 3.0.0 不再用找到幾份 source files 決定問法。沒有需要我們選擇的取捨，就直接提出有依據的建議；還有方向沒決定，才針對那個問題繼續問。談完後要寫文件，也會先說明準備建立或修改哪些檔案，等我們同意才動手。
所以，Spectra discuss 比較像是在回答：
這次要解決什麼問題，最後決定怎麼做、為什麼？
【Day - 9】的第一次 OpenSpec 實驗，我先用 Superpowers brainstorming，一題一題和 AI 談想做的功能，再把結果帶進 OpenSpec。那麼，這個 Skill 原本安排的流程是什麼呢？
我沒有保留當時安裝的精確版本，這裡先依第一次 OpenSpec 實驗期間的官方 brainstorming 內容來看。它會先讀取專案檔案、文件與近期 commits，了解目前的背景，再透過一次問一題的方式，確認想做什麼、有哪些限制，以及做到什麼程度才算完成。可以提供選項時，就盡量讓我們從選項中回答；一個主題還沒問清楚，就拆成幾個問題繼續談。
需求逐漸清楚後，AI 會提出 2～3 種作法，說明各自的優缺點，以及自己比較建議哪一種。選好方向後，再分段討論程式怎麼分工、資料怎麼傳、出錯時怎麼處理，以及準備怎麼測試。每談完一段，都先確認我們是否同意；有不清楚的地方，就繼續問。
設計確認後，Skill 會要求把結果寫進 docs/plans/ 下的設計文件，並提交到 Git。如果要繼續實作，會先詢問我們是否準備好了，再建立 Worktree，透過 writing-plans 整理實作計畫。我當時則把談好的需求帶進 OpenSpec，沒有繼續走 Superpowers 後面的流程。
現在有什麼不同？ 寫這篇鐵人賽文章時，目前的 brainstorming已經會先依工作範圍分流：可行性調查可以停在建議，既有功能的小幅修改可以只在對話中確認設計；新專案或架構調整才走完整設計文件與 writing-plans。文件位置也改成
docs/superpowers/specs/。這些是後來的調整，這篇仍以我開始使用時期的流程為主。
所以，brainstorming 比較像是在回答：
這個想法要怎麼做，才能整理成一份我們都確認過的設計？
grill-me：沿著決策樹安排提問Matt Pocock 的 grill-me 會先整理一份計畫、一個決定或想法裡，有哪些問題需要釐清，以及哪些問題必須等前面有了答案才能繼續。這些問題之間的關係，就是 decision tree（決策樹）。每一輪先處理目前能回答的問題，這一組問題稱為 frontier；還需要等待前面決定的，就留到後面再問。
AI 會把這一輪能回答的問題一起列出來，每題也附上自己的建議。等我們回答後，再看哪些後續問題已經可以繼續討論。查程式或環境就能知道的事，由 AI 自己查；需要我們決定的部分，才拿出來問。直到沒有還沒處理的問題，而且我們也確認彼此理解一致，才會結束。
grill-me 本身不會在 repo 留下文件。如果在專案目錄裡使用，官方的 workflow 導覽會改用 grill-with-docs，沿用相同的提問方式，並搭配 CONTEXT.md、ADR 等文件保存背景與決策。
所以，grill-me 想確認的是：
這個想法裡，還有哪些事情沒想清楚？每個決定的理由都說得通嗎？
這五種方式雖然都會和 AI 討論，但開始時需要準備什麼、問題怎麼問，以及談完會留下什麼，其實不太一樣。放在一起看，就比較容易知道什麼時候可以用哪一種：
| 方式 | 從哪裡開始？ | 主要怎麼談？ | 最後留下什麼？ |
|---|---|---|---|
| Spec Kit clarify（文件參考：0.0.79） | 已經存在的 spec.md |
找出會影響實作或驗證、卻還沒說清楚的地方，一次問一題 | 把答案補回原本的 spec |
| OpenSpec 1.0 explore | 還不清楚的想法、問題，或進行中的 change | 查程式、了解現況、比較可能的作法 | 不一定留下文件，需要時再整理討論結果 |
| Spectra 2.3.1 discuss | 一個想談清楚、得到結論的主題 | 先看相關程式碼，再列出假設讓我們確認，或一次問一題；也可以要求切換 | 整理決定與原因，並建議補進相關規格或規劃文件 |
| Superpowers brainstorming（文件參考：4.0.3） | 想做的功能與專案背景 | 逐題問清楚需求、比較作法，再分段確認設計 | 留下設計文件，決定繼續後再整理實作計畫 |
Matt Pocock 的 grill-me |
一份計畫、一個決定或想法 | 先問目前能回答的問題，再根據答案繼續追問 | 本身不留文件；改用 grill-with-docs 則會保存背景與決策 |
圖裡也整理了這五種方式從哪裡開始，以及談完後會往哪裡走：
把它們放在一起後，我才更清楚，同樣是和 AI 討論，有的是幫既有規格補上答案，有的是先找方向，有的則會一路帶著我們確認設計。除了怎麼問，談完後會留下什麼，也會影響我接下來怎麼使用這些內容。
對我來說，還有【Day - 14】提到的困擾需要處理：如果同時談了好幾個主題，有些已經決定、有些還沒談完，要怎麼留下來，下次才能接著談呢？接下來，我們就看看 Speclink 怎麼保存這些討論吧！
grill-me Skill
grilling Skill
ask-matt workflow 導覽
grill-with-docs Skill
iThome鐵人賽
看影片追技術