figure-it-out | 為複雜任務設計可稽核流程
本頁以 pstack-claude 0.9.126 為基準。figure-it-out 的第一個產物是為任務設計的工作流程，不是直接開始修改程式。
定位與適用情境
適合既有劇本無法完整涵蓋的大型遷移、多部分變更，或使用者離開後需要回頭稽核的工作。例如把三個付款供應商逐步接到統一介面，同時保留退款與錯誤回應契約。
輸入應包含現有整合點、目標介面、禁止改動範圍與可執行的驗證方式。只說「幫我全部處理好」不足以定義可否證的完成條件。
準備
- 定義完成條件，例如三個供應商的授權、請款、退款案例皆保留指定輸出，舊介面呼叫端歸零。
- 估計遷移單位與工作量，列出憑證、測試資料或工具缺口。不要把粗估當作完成時間保證。
- 區分可逆步驟與單向門 (One-way Door)，例如本機介面調整與正式資料遷移的風險不同。
- 指定決策紀錄存放位置與可寫檔案。任何 commit 或外部系統操作仍需獨立授權。
操作步驟
- Frame。 先讀 poteto-mode 的原則，理解現況，再交代完成條件、量化範圍、阻塞與嚴謹程度。把風險轉成關卡與產物，而不是只要求代理「更仔細」。多小時工作先展示框架與取捨。
- Design the workflow。 先捕捉修改前基準並建立驗證工具，再依最危險未知優先排序。拆成能獨立驗證的單位。涉及難逆轉的架構決策時用 architect，形狀已明確的機械遷移不重跑設計競賽。
- Run the loop。 每單位先寫假設，再做最小變更，對真實產物量測。有效才保留，無效則在授權範圍內撤回該變更。完成一單位的檢查再進下一單位，不把所有驗證拖到最後。
- Keep the audit trail。 過程中使用 show-me-your-work 留下決策理由、結果與證據路徑。若派工，另有評判者核對真實產物。關卡有問題就修正關卡，不能繞過它來取得通過。
- Verify and hand back。 最後對整體產品重跑原始完成條件。交付設計過的階段、嚴謹程度與理由、紀錄路徑、已證實項目及未決事項。
可直接使用的提示詞
可在 Claude Code 使用 /pstack:figure-it-out，或在 Codex 插件選單插入 $pstack:figure-it-out。以下是自然語言任務範例。
用 pstack:figure-it-out 規劃三個付款供應商的介面遷移。
先只產出工作流程與驗證設計，不修改程式、不連正式服務。
輸入是 src/payments/、現有契約測試與呼叫端。
完成條件是授權、請款、退款的既有對外結果保持一致，且舊介面呼叫端歸零。
先列基準擷取方式、最危險未知、原子工作單位、每單位的通過關卡。
正式資料遷移、憑證變更與部署必須停下確認。
規劃每單位如何記錄假設、實際命令、結果與決策。
證據不足標 INCONCLUSIVE，不把計畫完成當成遷移完成。預期結果與驗收
- 流程有具體順序，不是一般性的待辦清單。每個階段都有輸入、輸出與可失敗的關卡。
- 基準來自修改前的實際行為，能與修改後比較。測試工具通過不等於整個產品已通過。
- 實驗結論使用
VERIFIED、NOT VERIFIED或INCONCLUSIVE。不確定不能轉寫為成功。 - 決策紀錄能解釋為何保留或撤回變更。未獲授權的步驟與缺少資料的關卡保持開放。
限制與權限
這不是無條件自主執行的授權。原文鼓勵可逆工作前進，但正式資料變更、部署、刪除與其他不可逆動作仍須明確確認。
原文會組合 architect、show-me-your-work 與相關原則。實際使用前須確認安裝內容與工具可讀、可用。本頁不保證測試憑證、多代理或獨立評判者存在。必要的獨立審查缺席時不能宣稱已滿足關卡。
原文通常建議把稽核紀錄納入提交，方便後續審閱。這是交付建議，不取代使用者對可寫目錄、commit 與 push 的限制。