生產性思考

使用 Tim Hurson 的生產性思考模型引導一場結構化設計討論，並可選擇性地將其撰寫為 RFC。

輸入

$ARGUMENTS

將一切都奠基於程式碼中。 在每個步驟之前，搜尋並讀取與該步驟相關的檔案、架構圖、設定和文件，並在依賴它們時引用路徑。此工作坊相較於白板討論的價值在於，結論是基於系統實際的行為，因此請驗證而非假設。對於需要廣泛瀏覽大量檔案的情況，請委派給一個探索子代理，以便工作坊的上下文能專注於討論本身。
減輕使用者的負擔。 每次提問最多 5 個問題，並根據你所發現的內容附上你自己的建議答案，這樣使用者就可以回答「對，大致上是，但是…」，而不是從一張白紙開始。
每次一個步驟。 用像 步驟 2 / 6 — 什麼是成功？ 這樣的標題開始每個步驟，執行該步驟，然後停止並等待。僅在使用者準備好時才繼續；讓他們可以跳過、重新檢視或在步驟之間跳轉。
維護一個持續更新的筆記檔。 在每個步驟之後，將達成共識的結果附加到 <rfc-dir>/<slug>.notes.md（按照 RFC 模式步驟 3 中所述選擇 <rfc-dir>）。長時間的工作坊會壓縮或稍後恢復；筆記檔讓 RFC 模式或新的工作坊能夠在未遺失決策的情況下接續進行。在第一次建立筆記檔時告訴使用者它位於何處。

目標：對現狀和目標未來達成共同理解。探索受影響區域的既有實作、呼叫點、資料模型和最近的 git 歷史紀錄。包含：痛點或瓶頸（附上如錯誤、指標或程式碼等證據）、受影響的模組和服務、哪些人受到影響，以及「解決問題」後的樣貌。

目標：所有選項都將據以評判的標準。從步驟 1 提出一個草案，並讓使用者修正。

也要捕捉明確的非目標。

提出 2–3 個以不同角度框架挑戰的「我們該如何…」問題，例如一個狹隘的問題和一個挑戰步驟 1 中某個假設的問題。使用者選擇或改寫一個；這將成為工作坊後續問題陳述。

提出 2–3 個真正不同的方法，這些方法必須奠基於程式碼庫，而非同一個點子的變體。針對每個方法：簡短描述、它會觸及的檔案或模組，以及其主要風險。在此步驟中暫緩判斷，並邀請使用者提出自己的想法。

根據 DRIVE 標準為每個方法評分（使用小型表格效果很好），推薦其中一個，並說明你正在接受的取捨。然後強化它：失效模式、邊界情況、遷移考量、未解決的問題。記錄其他選項落選的原因；這將成為「已考慮的替代方案」的內容。

就交付形式達成一致，而非個別的任務：階段或里程碑以及每個階段能展示什麼、最需要優先驗證的風險部分、功能開關和遷移策略、測試策略、部署與回滾，以及需要監控的項目。詳細的任務分解將在稍後由 /task-breakdown 完成，該工具會以 RFC 為基礎進行。最後，提議產生 RFC。

尋找工作坊：利用到目前為止的對話內容以及筆記檔（如果存在的話）。如果完全沒有工作坊，請說明並提議開始一個新的：要求問題陳述並開始步驟 1。
如果有缺失的步驟，列出它們，並詢問是要現在填補，還是草擬 RFC 並將這些區段標記為待決定。請勿憑空創造使用者未做出的決定。
選擇輸出的位置。RFC、筆記和任務檔案是開發者的本地工作文件：預設不進行追蹤，不與程式碼一起提交。尋找已存在的本地、被 git 忽略的資料夾（檢查 .gitignore 和 .git/info/exclude）並遵循其命名慣例。如果沒有，則提議 .rfcs/YYYY-MM-DD-<slug>.md，並將 .rfcs/ 加入 .git/info/exclude，這會在不變更儲存庫的 .gitignore 的情況下在本地忽略它。僅在使用者說團隊會提交 RFC 時，才使用如 docs/rfcs/ 這樣的追蹤資料夾。
使用 templates/rfc.md 撰寫 RFC，根據工作坊內容填寫每個區段，並將程式碼庫的主張與檔案路徑連結。
告知使用者路徑，並列出任何待決定區段與未解決問題。
提供下一步：/task-breakdown <rfc-path> 將 RFC 轉換為團隊可以接手處理的 1 個故事點任務。