Termdock三個任務，先分好邊界
這篇文章用電商專案做示意：商品搜尋、購物車和訂單確認信分別交給三個 Claude Code session。先建立共用規格，再讓三個 session 在不同 Git worktree 工作，最後檢查 diff、測試及整合順序。
這是可調整的流程範例，不是可供核對的實測紀錄。先前版本聲稱 40 分鐘完成且所有測試通過，但沒有提供執行紀錄，本文不把這些數字當成結果。平行處理也不保證比較快；整合與審查仍需要時間。
環境準備
準備一個你有權修改、已有 commit 的練習 repository，安裝 Git、Claude Code 和 Termdock。先確認 Claude Code 的帳號資格、用量及權限。執行 git status 和 git worktree list，確認現有修改及 worktree，保護尚未提交或不可替代的資料。範例中的 branch 和目標目錄必須不存在；若已存在，先停下來查明，不覆寫。
Worktree 是不同工作目錄，但仍共用同一個 Git repository，不是安全 sandbox。需要隔離憑證、網路或檔案時，另用適當的權限或隔離環境。
第一步：確認共享規格
先寫清楚三個任務的需求、共用型別、API 介面、允許修改的檔案及測試命令。確認規格已在選定的基礎 commit 中，且本機狀態可安全使用。不要用 cat > 覆寫已有的型別檔；若需修改共用檔案，先閱讀現有內容、保留備份並由你決定是否提交。
例如，搜尋負責 app/search/ 與 lib/search/，購物車負責 app/cart/ 與 lib/cart/，郵件負責 lib/email/。若都需要改 app/layout.tsx 或共用設定，先指定單一負責者，避免同時修改。
第二步：建立 Worktree 並開啟 Termdock
下面以目前的 HEAD 當共同基礎；先確認它是你剛檢查過的 commit。以下建立新分支，不是開啟已存在分支：
git worktree add -b feature/product-search ../project-search HEAD
git worktree add -b feature/cart ../project-cart HEAD
git worktree add -b feature/order-email ../project-email HEAD
git worktree list
在 Termdock 開三個終端，分別切入這三個目錄並用 pwd、git status 確認工作位置，再啟動已安裝的 claude。Termdock 能辨識既有 worktree，但不會替每個 agent 自動建立一份。
也可依 Claude Code worktree 文件使用 claude --worktree <name>，但這條路徑和分支由 Claude Code 管理，預設分支名有 worktree- 前綴，基礎 commit 和清理行為也依設定與版本而異。不要把它產生的名稱直接當成上面手動建立的 feature/... 分支。
第三步：給每個 Agent 明確任務
每個 session 都要取得共用規格及自己的責任，例如：
依照已提交的規格完成商品搜尋。
只修改 [填入授權檔案或目錄]，不要改共用設定或其他 agent 的檔案。
執行 [填入已確認的測試命令]，回報 branch、diff、實際測試結果及尚未完成事項。
不要提交、合併或部署，除非我另行要求。
把方括號換成實際內容，購物車和郵件 session 也分別提供自己的範圍。需要外部郵件服務時，先用測試設定，未獲授權不要發送真實郵件。
第四步：用 Termdock 交接成果
各 agent 回報後，把三份 worktree 路徑、branch、diff、測試輸出與未解問題交給協調 session。請它先核對共用型別、依賴順序及重疊檔案，再列出需要人工確認的項目。可以手動傳遞，也可以參考 Termdock CLI／API 交接教學讓 agent 送任務並讀取回覆。
不同 session 不會自動共享上下文；終端停止輸出也不代表任務成功。核對實際檔案和測試結果，缺少的結果標為待查。
第五步：審查、整合與驗證
在各 worktree 檢查 git status 和 diff，確認只改了授權範圍。依已確認的依賴順序，由你決定是否提交並合併每個 branch；發生衝突時逐項處理，不把它當作一定能自動解決的工作。
整合後依專案實際指令執行 build、相關測試及必要的瀏覽器檢查，保留命令和結果。確認寄信流程只使用測試資料及測試服務。只有測試真的通過，才記錄為通過；未執行或失敗的項目要明確列出。
第六步：確認後再清理
清理前再次查看 git worktree list、每個 worktree 的未提交與未追蹤檔案，以及尚未整合的 commit。不可替代或使用者擁有的資料要先建立並驗證可讀備份；Git 不代替備份。確認內容已保留且獲得授權後，再依 Git worktree 文件移除不再需要的 worktree 或分支。
什麼時候值得平行
適合分工清楚、可分開驗證且有能力審查整合結果的工作。若任務高度相依、共用檔案很多或需要接觸敏感系統，先循序處理可能更簡單。記錄自己的完成時間、測試、返工和用量，再判斷這種配置是否值得。