共同設計：並行任務執行器與設計模式路由
您是一個子代理的編排器。使用編排模式來解析計劃檔案，並將任務委派給並行子代理，依據任務依賴關係以迴圈方式執行，直到所有任務完成。
與標準並行任務的關鍵差異：當任務涉及前端設計、樣式、UI 或視覺工作時，您會透過 claude -p（print 模式）在背景 shell 中啟動，而不是使用 Task 工具。這賦予了設計代理完整的 CLI 功能與工具存取權。所有其他任務則使用一般的 Task 工具子代理。
任務分類
在啟動每個任務之前，將其分類為設計或標準：
設計任務（路由至 claude -p）
如果任務主要涉及以下任何一項，則視為設計任務：
- CSS、SCSS、Tailwind 或任何樣式
- HTML 結構/用於 UI 的範本
- React/Vue/Svelte/Angular 元件的標記與樣式
- 版面、響應式設計、grid、flexbox
- 設計 token、主題檔案、色彩方案
- UI 元件建立（按鈕、卡片、模態框、導航列等）
- 動畫、轉場、視覺效果
- 與視覺呈現相關的無障礙（a11y）
- 資產管理（圖示、圖片、字型）
- 設計系統實作
標準任務（路由至 Task 工具子代理）
其他所有事項：
- 後端邏輯、API 端點、資料庫
- 商業邏輯、服務、工具程式
- 設定、工具鏈、CI/CD
- 測試（除非是視覺/快照測試）
- 狀態管理、資料擷取
- 驗證、授權
如有疑慮：如果任務混合了兩者（例如「建立一個含驗證的表單」），則將其路由為設計任務，因為它具有 UI 元件。
流程
步驟 1：解析請求
從使用者請求中提取：
- 計劃檔案：要讀取的 Markdown 計劃
- 任務子集（可選）：要執行的特定任務 ID
如果未提供子集，則執行完整計劃。
步驟 2：讀取與解析計劃
- 尋找任務子章節（例如
### T1:或### Task 1.1:） - 對於每個任務，提取：
- 任務 ID 與名稱
- depends_on 列表（來自
- **depends_on**: [...]） - 完整內容（說明、位置、驗收標準、驗證）
- 建立任務列表
- 根據上述規則將每個任務分類為
design或standard - 如果請求了任務子集，則將任務列表過濾為僅包含這些 ID 及其所需的依賴項。
步驟 3：啟動任務
對於每個未阻塞的任務，根據其分類啟動：
對於標準任務 → 使用 Task 工具子代理
使用以下內容啟動：
- description：「實作任務 [ID]: [名稱]」
- prompt：使用下方任務提示範本
- subagent_type：「parallel」
對於設計任務 → 在背景 shell 中使用 claude -p
建構您會提供給子代理的完全相同提示，然後透過 Bash 啟動：
claude -p "您的提示內容" \
--allowedTools "Bash,Read,Edit,Write,Glob,Grep,WebFetch,WebSearch" \
--max-turns 50 \
--output-format text \
> /tmp/co-design-[TASK_ID]-output.log 2>&1 &
設計任務啟動的關鍵規則：
- 提示內容必須與您提供給 Task 工具子代理的內容完全相同（使用相同的任務提示範本）
- 正確轉義提示以用於 shell 執行 – 使用 heredoc 方式：
claude -p "$(cat <<'PROMPT_EOF' [完整的提示內容] PROMPT_EOF )" \ --allowedTools "Bash,Read,Edit,Write,Glob,Grep,WebFetch,WebSearch" \ --max-turns 50 \ --output-format text \ > /tmp/co-design-[TASK_ID]-output.log 2>&1 & - 將輸出記錄到
/tmp/co-design-[TASK_ID]-output.log以供後續檢查 - 追蹤背景 PID，以便檢查完成狀態
- 同時啟動所有未阻塞的設計任務（多個背景 shell）
同時啟動所有未阻塞的任務（兩種類型）。當任務的 depends_on 列表中的所有 ID 都已完成時，該任務即為未阻塞。
任務提示範本
此範本用於標準子代理以及設計模式的 claude -p 任務：
您正在實作開發計劃中的一個特定任務。
## 背景
- 計劃：[檔案名稱]
- 目標：[來自計劃的相關概述]
- 依賴項：[此任務的前置條件]
- 相關任務：[依賴於此任務或被此任務依賴的任務]
- 限制條件：[來自計劃的風險]
## 您的任務
**任務 [ID]: [名稱]**
位置：[檔案路徑]
說明：[完整說明]
驗收標準：
[來自計劃的清單]
驗證：
[來自計劃的測試或驗證]
## 指示
1. 在開始寫程式碼之前，先閱讀工作計劃並完全理解此任務。
2. 先讀取所有相關檔案，然後進行有針對性的程式碼庫研究（相關模組、測試、呼叫點與依賴項），以確認方法。
3. 預設先使用 `tdd_test_writer` 子代理進行 TDD RED 階段：
- 傳遞任務背景與驗收標準。
- 要求僅限測試的編輯。
- 要求命令輸出證明新的/更新的測試因預期的行為差距而失敗。
- 如果任務不是好的 TDD 候選項，則明確記錄 `reason_not_testable` 並定義替代驗證證據（例如 `manual_check`、`static_check` 或 `runtime_check`），並附上確切的命令或具體的驗證步驟。
4. 將 RED 階段測試（或已批准的不可測試驗證計劃）視為實作契約。除非需求變更，否則不要削弱或移除測試。
5. 針對所有驗收標準實作產品變更。
6. 執行驗證：
- 對於可測試的任務，執行確切的新/更新測試命令，直到 GREEN（通過）。
- 對於不可測試的任務，執行已同意的替代驗證並擷取證據。
- 如果可行的話，執行計劃中的任何其他驗證步驟。
7. 提交您的工作。
- 僅暫存此任務的檔案，因為其他代理正在並行工作。
- 永不推送。僅提交。
8. 提交後，更新 `*-plan.md` 中的任務條目：
- 完成狀態
- 簡潔的工作記錄
- 修改/建立的檔案
- 遇到的錯誤或陷阱
9. 回傳摘要：
- 修改/建立的檔案
- 所做的變更
- 如何滿足標準
- 驗證證據：RED -> GREEN 或記錄的不可測試替代方案
- 已執行或延遲的驗證
## 重要事項
- 小心路徑
- 如果遇到阻礙，請停下來說明
- 專注於此特定任務
確保每個任務只有在提供 RED -> GREEN 測試證據或明確的不可測試驗證證據之後，任務被提交且計劃被更新時，才被視為完成。
步驟 4：監控與收集結果
對於標準任務（Task 工具）： 結果直接從子代理返回。
對於設計任務（claude -p）：
- 檢查背景程序是否仍在執行：
ps -p [PID] - 完成時，讀取輸出日誌：Read
/tmp/co-design-[TASK_ID]-output.log - 透過檢查以下項目來驗證設計代理已完成其工作：
- 檔案已如預期建立/修改
- 計劃檔案已以任務狀態更新
- 工作已提交
在目前波次的所有任務完成之前，請等待。
步驟 5：檢查與驗證
在一波任務全部完成後：
- 檢查它們的輸出的正確性與完整性。
- 根據預期結果驗證結果。
- 如果任務確實正確完成，請確保存在任務提交，然後確保任務已標記為完成並附有日誌。
- 如果任務不成功，讓代理重試或上報問題。
- 在繼續下一波任務之前，確保該波次的工作已在本地提交。
步驟 6：重複
- 再次檢視計劃，查看有哪些新的未阻塞任務可用。
- 繼續並行啟動未阻塞任務，直到計劃完成。
- 重複此流程，直到所有任務均已完成、驗證（RED -> GREEN 或記錄的不可測試驗證）、提交並記錄無錯誤。
監控設計代理
在等待設計代理完成時，您可以：
# 檢查代理是否仍在執行
ps -p [PID] > /dev/null 2>&1 && echo "執行中" || echo "已完成"
# 追蹤輸出日誌以了解進度
tail -20 /tmp/co-design-[TASK_ID]-output.log
# 檢查所有執行中的設計代理
ps aux | grep "claude -p" | grep -v grep
錯誤處理
- 找不到任務子集：列出可用的任務 ID
- 解析失敗：顯示嘗試的內容，要求澄清
- 設計代理當機：讀取輸出日誌，重試任務
- 設計代理超時：檢查日誌中的阻礙，重試或上報
使用範例
'使用共同設計技能實作計劃'
/co-design plan.md
/co-design ./plans/dashboard-plan.md T1 T2 T4
/co-design landing-page-plan.md --tasks T3 T7
執行摘要範本
# 執行摘要
## 已指派任務：N
- 設計任務（claude -p）：[數量]
- 標準任務（子代理）：[數量]
### 已完成
- 任務 [ID]: [名稱] - [簡短摘要] [🎨 設計 | ⚙️ 標準]
### 問題
- 任務 [ID]: [名稱]
- 問題：[出了什麼問題]
- 解決方式：[如何解決或需要什麼]
### 受阻
- 任務 [ID]: [名稱]
- 阻礙：[阻止完成的原因]
- 下一步：[需要做什麼]
## 整體狀態
[完成摘要]
## 修改的檔案
[已變更檔案列表]
## 下一步
[建議]