Trellis 腦力激盪是做什麼的？

不可協商的規劃合約

請求建置、實作、修正、重構或「開始進行」不代表同意跳過規劃。任務建立同意也不等於實作批准。

對於每個非瑣碎任務，用戶在初始請求後必須至少回應一次，然後才能開始實作。如果無需釐清，該回應必須批准下方所述的最終規劃摘要。

在任何用戶擁有的產品、範圍、使用者體驗、相容性、風險或驗收決定尚未解決時，每次回合結束時只能提出一個最高價值的問題。不得編輯產品程式碼、分派實作或執行 task.py start。

不可協商的證據規則

如果一個問題可以透過探索程式碼庫來回答，則改為探索程式碼庫。

這是強制性的。在詢問用戶問題之前，請先檢查答案是否已經存在於程式碼、測試、設定、文件、現有規格或任務歷史記錄中。

不要要求用戶確認儲存庫可以回答的事實。僅詢問那些經檢查後仍模糊不清的產品意圖、偏好、範圍、風險容忍度、驗收行為或決策。

儲存庫證據確立了當前行為和技術限制。用戶的意圖行為、功能範圍邊界和 UX 偏好絕非僅靠儲存庫證據就能回答，即使存在現有模式；現有模式是選項和建議證據，而非決策。

在第一階段規劃中使用此技能，將用戶的請求轉化為清晰的需求和規劃產出。

前置條件

僅在任務建立同意已給予且用戶準備好進入 Trellis 規劃時使用此技能。

如果尚無任務，請建立一個：

TASK_DIR=$(python3 ./.trellis/scripts/task.py create "<簡短任務標題>" --description "<一行摘要>" --slug <slug>)

使用用戶請求中的簡潔標題。標題和 --description 都必須非空 — create 會拒絕空白，且任一欄位為空的記錄在歸檔時會被拒絕。使用不包含日期前綴的 slug。task.py create 會自動新增 MM-DD- 目錄前綴。

task.py create 會建立預設的 prd.md。在提出後續問題之前，請使用當前的理解更新該檔案。

規劃流程

將用戶的請求和初始已知事實記錄到 prd.md 中。
在提問之前，檢查可用的證據：
- 程式碼、測試、fixture 和設定
- README 檔案、文件、現有規格和領域筆記
- 相關的 Trellis 任務、研究檔案和（如果存在）會話歷史記錄
將發現的內容分為：
- 已確認的事實
- 仍需用戶提供的產品意圖
- 仍需用戶做出的範圍或風險決策
- 可能超出範圍的項目
如果仍有用戶擁有的決策待解決，則提出一個最高價值的問題，附上您的建議和取捨，然後停止。請勿在同一回合中執行實作工作。
每次用戶回答後，更新 prd.md，重新計算決策清單，並從步驟 2 重複進行。
當不再有用戶擁有的決策需要解決時，為複雜任務建立或更新 design.md 和 implement.md。
執行需求收斂檢查點，然後執行 PRD 收斂通關。
呈現最終規劃摘要並停止。請勿在同一回合中執行 task.py start 或編輯產品程式碼。
只有當用戶在後續訊息中明確批准最新的最終規劃摘要時，才授權執行 task.py start 和開始實作。如果在批准後，產出物發生重大變化，請重複最終審查。

不要發明特定於專案的產品/規格層級結構。如果儲存庫已有產品、領域或規格文件，請使用它們。如果沒有，則使用現有證據進行。

提問規則

每則訊息只能問一個問題。

每個問題必須包含：

需要做出的決定
為何這個答案很重要
您建議的答案
如果用戶做出不同選擇的取捨

不要詢問流程問題，例如是否要搜尋、檢查檔案或繼續腦力激盪。直接進行證據調查。僅在剩餘問題是產品決策、偏好、範圍邊界或風險容忍度選擇時才詢問用戶。

建議並非預設選擇。切勿僅僅因為用戶要求實作，就代表用戶選擇建議的產品決策。

當請求與儲存庫證據已經解決了所有決策時，不要編造釐清問題。在這種情況下，直接進入最終規劃摘要，該摘要仍然需要後續的明確批准。

最終審查是必要的階段轉換關卡，並非禁止的流程問題。任務建立同意、初始實作請求以及在最新最終摘要之前給予的批准，並不能滿足此關卡。

思考架構：第一原則分析

當需求模糊、解決方案感覺過度設計，或者您正要因為「大家都這麼做」而增加複雜性時 — 先分解到基本真理，再向上推理。

步驟 1：重新陳述問題

剝離實作細節，簡化成一句話。

不好：「我們需要在用戶資料端點加入 Redis 快取」好：「用戶資料載入時間過長」

步驟 2：列出基本真理

哪些是絕對真實的（不是意見或慣例）？

類別	範例
物理限制	網路延遲 ≥ 0，磁碟 I/O 有限制
業務規則	「用戶必須看到自己的資料」
技術不變量	「資料必須一致」
用戶需求	「用戶希望在 Y 秒內得到 X」

步驟 3：挑戰假設

針對當前計劃的每個組成部分：

事實還是慣例？ 「我們總是使用 REST」 — 為什麼？
如果我們移除這個會怎樣？ 如果沒有任何東西壞掉，那就是不必要的。
解決實際問題還是症狀？ 追溯因果鏈。
誰從這種複雜性中受益？ 如果「沒有人」，那就簡化。

步驟 4：從真理開始建構

從滿足所有真理的最小可行機制開始
僅當特定真理要求時才增加複雜性
每次增加都必須回答：「哪個真理需要這個？」

步驟 5：驗證

解決方案是否解決了原始問題？
哪些假設需要驗證？
測試這個假設最簡單的實驗是什麼？

需求收斂檢查點

在最終審查之前，驗證以下所有項目：

用戶成果和產品價值是明確的
範圍內和範圍外的行為是明確的
驗收標準描述可觀察的結果
用戶擁有的產品、範圍、使用者體驗、相容性和風險決策已解決
阻礙性的未解決問題為空
技術未知已研究過，或明確地延遲處理而不改變 MVP 行為

輕量級任務可以省略 design.md 和 implement.md；但不能跳過證據檢查、需求收斂、最終審查或全新的實作批准。

最終規劃摘要必須顯示目標、範圍內、範圍外、驗收標準、關鍵決策、相關風險或延遲項目，以及產出物狀態。

產出物規則

prd.md 記錄需求和驗收：

目標和用戶價值
已確認的事實
需求
驗收標準
範圍外
仍阻礙規劃的未解決問題

design.md 記錄複雜任務的技術設計：

架構和邊界
資料流和合約
相容性和遷移注意事項
重要的取捨
營運或回滾考量

implement.md 記錄複雜任務的執行計畫：

有序的實作檢查清單
驗證命令
風險檔案或回滾點
執行 task.py start 前的後續檢查

輕量級任務可能只有 prd.md。複雜任務在 task.py start 之前必須有 prd.md、design.md 和 implement.md。

implement.md 不能取代 implement.jsonl。在子代理分派工作流程中，implement.jsonl 和 check.jsonl 在執行 task.py start 之前，都必須至少包含一個真實的規格/研究條目；空清單或僅包含舊版 _example 佔位符資料列的清單不算數。內聯工作流程會跳過此 JSONL 關卡，因為第二階段會透過 trellis-before-dev 載入上下文。

PRD 收斂通關

在宣告規劃準備就緒或執行 task.py start 之前，根據上述產出物規則中描述的最終結構，重寫 prd.md 一次。這不是可選的清理工作；這是最終的規劃關卡。

此通關必須是無損的：

將重複的事實合併到一個權威章節中。
將臨時的腦力激盪章節（例如「我已經知道的」、「假設」和已解決的「未解決問題」）歸入目標、背景、需求、技術說明或驗收標準。
移除已解決的未解決問題，而不是留下空白或已回答的章節。
當並列的錯誤清單和需求清單描述相同的工作時進行合併；將每個缺陷的嚴重性、證據和檔案:行號錨點保留在所屬的需求上。
保留每一個檔案:行號錨點、決策、限制條件、需求 ID 和驗收標準映射。
在仍有任何阻礙性未解決問題時，不得進入最終審查。

通關後，從頭到尾閱讀 prd.md，並驗證沒有任何事實跨章節重複，除非該重複增加了新資訊。

品質標準

在宣告規劃準備就緒之前：

prd.md 包含可測試的驗收標準。
prd.md 已通過 PRD 收斂通關：沒有未解決的臨時腦力激盪章節、沒有跨章節的重複事實、也沒有遺失的錨點、決策或驗收映射。
可透過儲存庫回答的問題已透過檢查得到回答。
阻礙性的未解決問題為空。
複雜任務已有 design.md 和 implement.md。
子代理分派任務在 implement.jsonl 和 check.jsonl 中都有真實策劃的條目；僅有種子清單不算準備就緒。
最新的最終規劃摘要已呈現給用戶。
在後續訊息中，用戶明確批准了該摘要用於實作。

不要僅僅因為用戶最初要求實作就開始實作。

Trellis 腦力激盪