architect | 先定介面與模組形狀
本頁以 pstack-claude 0.9.126 為基準。architect 先產出型別、函式簽章與模組草圖，再讓實作填入已選定的形狀，不是先寫完程式才補架構說明。
定位與適用情境
適合需求會跨越函式或模組邊界，而且責任歸屬尚未確定的工作。例如替匯出服務加入「可取消的背景匯出」，必須先決定工作狀態由誰保存、取消如何回應，以及呼叫端會看見哪些結果。
輸入是現有匯出流程、相關呼叫端與新需求。輸出先是呼叫端使用範例、型別草圖與決策理由。若授權實作，之後才把草圖中的 not implemented 與偽程式碼換成實作。
準備
- 指定既有入口、狀態儲存位置、錯誤處理與測試路徑。不要只提供一個檔名。
- 寫下行為契約，例如取消後不得再發送下載通知，以及已完成工作被取消時應回傳什麼。
- 決定是否需要人工檢查點 (Checkpoint)。原文預設會從設計直接進入實作，想只看草圖必須明說。
- 核對平台能否建立隔離工作區與啟動子代理 (Subagent)。本頁不代表讀者的環境已具備這些工具。
操作步驟
- 理解現況。 以 how 追蹤匯出請求到通知的資料流。若要改變擁有權或分層，再以 why 查明現有安排的理由。只有真正不需整合既有系統的全新工作才略過這步。
- 競爭草圖。 透過 arena 產出至少兩種結構不同的候選，例如集中式工作狀態機與由工作物件持有生命週期。先寫呼叫端用法，再推導型別與簽章。比較不變條件、公開介面大小及維護者需要理解的內部細節。
- 保存選定契約。 寫出模組責任、結果種類、被拒絕方案與合成決策。若指定檢查點，此時停下確認，不把設計通過視為實作授權。
- 依草圖實作。 每個單位完成前比對介面與責任。已核准的契約變更要回寫同一份草圖與理由，記錄核准依據。未接受的偏離保持可見，不為遷就程式而偷偷改規格。
- 辨認錯誤形狀。 若不同位置反覆需要同類轉型、例外分支或洩漏內部規則，重新理解已寫程式並回到競爭草圖。單一合理邊界案例不等於整個架構失敗。
可直接使用的提示詞
以下是自然語言需求。Claude Code 可用 /pstack:architect，Codex 插件可從技能選單插入 $pstack:architect。skills-only 安裝的名稱不帶 pstack:。
用 pstack:architect 設計背景匯出的取消功能，先停在草圖，不實作。
輸入是 src/export/、其呼叫端與現有匯出測試。
先追蹤工作建立、狀態更新與通知，再比較至少兩種責任配置。
取消成功後不得再送下載通知。已完成工作不得被改回取消狀態。
先展示呼叫端用法，再給型別、函式簽章、模組責任與選擇理由。
把無法從現有程式確認的需求列成未決事項。
若缺少多代理或隔離工具，明說降級方式，不聲稱完成獨立競爭設計。
等我確認草圖與實作範圍後才改應用程式碼。預期結果與驗收
- 小型變更可是一份型別與簽章草圖。大型變更還要有模組圖與並列的設計理由。
- 至少兩種結構候選有實質差別，不是同一個方案換名稱。
- 每個取消結果都能對應到呼叫端可觀察的契約。狀態由誰修改可從草圖讀出。
- 若進入實作，每個已接受偏離都已同步至設計，下一位實作者不會拿到互相矛盾的指示。
- 草圖本身不是功能完成證據。還要執行取消與通知路徑的實際驗證。
限制與權限
architect 會呼叫 arena，不能假設任何平台都提供相同模型或平行派工工具。Codex 對應使用 spawn_agent，缺少能力時需標示序列替代及獨立觀點缺口。
原文還引用 runner-prompt.md、design-red-flags.md 與 rationale-template.md。本次提供的來源快取未含這三份附件，因此本頁不重建其逐項規則，也不宣稱已依附件完成檢核。實際使用前應確認安裝包是否包含它們。
原文允許把草圖獨立提交，但技能不是 commit、push 或擴大修改範圍的授權。草圖暫時不能執行，也不應被誤報為可交付功能。