/design — 開發設計
接收功能需求，自動盤點可用的 ECC 資源（agents/skills/commands），建立完整實作計畫並輸出至 plans/active/<slug>.md。不會自動執行實作，必須等使用者確認。
Step 0: 任務追蹤（條件式 HITL）
評估本次任務是否適合啟用 task tracking。
判斷依據：
| 建議啟用 | 建議跳過 |
|---|---|
| 預估 4+ 實作步驟 | 1-3 個簡單步驟 |
| 有步驟間依賴關係 | 線性無依賴 |
| 跨多個檔案/模組 | 單一檔案修改 |
| 預計執行時間較長 | 快速完成的任務 |
若判斷為「建議啟用」： 使用 AskUserQuestion 詢問使用者：
本次任務較為複雜（[簡述原因]），建議啟用任務追蹤。
啟用後會在每個步驟使用 TaskCreate/TaskUpdate 追蹤進度， 支援依賴管理（addBlockedBy）和即時狀態顯示（activeForm）。 預估額外 token 消耗：~500-1,000 tokens。
- 啟用 — 全程追蹤
- 不啟用 — 直接開始
若判斷為「建議跳過」： 不詢問，直接進入 Step 1。
啟用後的行為：
- TaskCreate 父任務（subject:
/design: [需求摘要]） - 每個 Step 開始前 TaskCreate 子任務（含 activeForm），保留回傳的 task ID，完成後 TaskUpdate 為 completed
- 有依賴的步驟使用 addBlockedBy 標記（填入前序步驟 TaskCreate 回傳的 task ID）
- 不啟用則完全跳過所有 Task 工具呼叫
Step 1: 盤點 ECC 資源
若啟用 task tracking： TaskCreate(subject: "盤點 ECC 資源", activeForm: "掃描 agents/skills/commands 中...") → 完成後 TaskUpdate(status: "completed")
掃描所有可用的 ECC agents、skills 和 commands，作為後續規劃的參考。
掃描方式：
- 列出所有可用的 agent types（從 Agent tool 的 subagent_type 列表），包括 v1.8 新增的
harness-optimizer（harness 設定優化）和loop-operator（自主迴圈監控） - 列出所有可用的 skills（從 system-reminder 中的 skill 列表）
- 列出所有可用的 commands（從
~/.claude/commands/和 plugin commands），包括 v1.8 新增的/harness-audit、/quality-gate、/loop-start - 根據使用者的需求（
$ARGUMENTS），篩選出相關的資源
輸出： 一份簡潔的資源清單，標記每個資源與當前需求的關聯程度（高/中/低）。
Step 2: 複雜度評估
根據需求規模，選擇執行路徑：
| 複雜度 | 判斷標準 | 執行路徑 |
|---|---|---|
| 低 | 單一檔案、不涉及架構變更（例：更新 README、加 badge、改設定） | 跳過 Step 4（architect），直接 Step 3 → Step 5 |
| 中等以上 | 跨檔案或有架構影響 | 完整流程 Step 3 → Step 4 → Step 5 |
如果需求過於模糊無法判斷複雜度，使用 AskUserQuestion 請使用者補充具體資訊。
無論走哪條路徑，都會輸出 plans/active/<slug>.md。
Step 3: planner — 建立實作計畫
若啟用 task tracking： TaskCreate(subject: "planner 建立實作計畫", activeForm: "planner agent 規劃中...") → 完成後 TaskUpdate(status: "completed")
使用 planner agent 建立詳細的實作計畫。
Agent(subagent_type="everything-claude-code:planner")
輸入 context：
- 使用者的需求描述（
$ARGUMENTS+ 對話脈絡） - Step 1 盤點的 ECC 資源清單
- 當前專案結構（透過
ls、git status等了解）
計畫須包含：
- 需求拆解 — 將需求分解為可執行的子任務
- 技術方案 — 每個子任務的實作方式
- 業界實踐與標準化方案參照 — 每個技術方案須附上依據
- 是否有業界標準或慣例（RFC、W3C、OWASP、12-Factor 等）
- 是否有學術研究支撐（論文、benchmarks）
- 是否有成熟的標準化解決方案（官方 SDK、知名 library 的 canonical pattern）
- 若無直接標準，說明為何採用自訂方案，並引述最接近的參考
- ECC 資源整合 — 明確指出每個步驟應使用哪個 agent/skill/command。ECC 資源分配須經盤點確認 — 不可假設資源可用，須回溯 Step 1 的盤點結果
- 例：「Step 3: 使用 tdd-guide agent 撰寫測試」
- 例：「Step 5: 使用 /code-review 進行品質審查」
- 依賴關係 — 哪些步驟必須按順序執行、哪些可以並行
- 風險評估 — 潛在的技術風險和對策
- 驗收標準 — 怎樣算完成
Step 4: architect — 架構設計審查
若啟用 task tracking： TaskCreate(subject: "architect 架構審查", activeForm: "architect agent 審查中...", addBlockedBy: [Step 3 TaskCreate 回傳的 task ID]) → 完成後 TaskUpdate(status: "completed")
使用 architect agent 審查 Step 3 的計畫。
Agent(subagent_type="everything-claude-code:architect")
審查重點：
- 架構是否合理、可擴展
- 是否有更簡單的替代方案
- 與現有程式碼的相容性
- 效能和安全性考量
- 業界/學術參照的可靠性 — 引用的標準是否適用於當前情境、是否為最新版本、有無更好的標準化方案被遺漏
- ECC 資源的選用是否恰當 — 須對照 Step 1 盤點結果，確認所選 agent/skill 在當前 session 可用
- 文件影響評估：實作後需要新增或更新哪些文件（README、API docs、CODEMAPS），列入 plan 待辦
如果有重大架構建議： 回饋給 planner 調整計畫（最多迭代 2 次）。
Step 5: 生成 Slug 並輸出 plan
若啟用 task tracking： TaskCreate(subject: "生成 slug 並輸出 plan", activeForm: "品質檢查與輸出中...") → 完成後 TaskUpdate(status: "completed")
將最終計畫寫入檔案前，先對照以下檢查清單確認計畫品質：
| 維度 | 通過標準 |
|---|---|
| 完整性 | 每個需求都有對應的實作步驟 |
| 可執行性 | 每個步驟有明確的檔案路徑和具體動作 |
| 依賴正確性 | 步驟間依賴無環且順序合理 |
| 粒度適當 | 每個步驟 1-3 個具體動作 |
| ECC 資源合理 | 每個 agent/skill 在其設計用途內使用 |
| 驗收可測 | 每個驗收標準都可客觀驗證 |
| 業界/學術支撐 | 每個技術方案都有明確的業界標準、學術研究或標準化方案參照 |
| 實作後工具 | plan 的步驟中包含實作後的品質保障（code-reviewer、/update、/verify 等） |
| Eval 基線 | 若涉及行為變更，計畫中包含 eval 基線建立與回歸驗證步驟（參考 /quality-gate） |
如果發現問題，直接修正計畫內容。
Slug 生成規則：
從 plan 的 H1 標題（# Implementation Plan: <名稱>）生成 kebab-case slug：
- 取
:後的標題部分（去除Implementation Plan:前綴） - 保留英文字母、數字、
-；中文字跳過 - 空格和特殊字元轉
-，連續-合併，兩端修剪 - 全部小寫，截斷至最多 60 字元
- 若結果為空（純中文標題），使用
plan-YYYYMMDD
範例：
PDT-8953 過濾 abstract 中的 URL→pdt-8953-urlStripe Subscription Billing→stripe-subscription-billing
輸出路徑： plans/active/<slug>.md（相對於專案根目錄）
- 若目錄不存在，自動
mkdir -p plans/active/ - 若同名檔案已存在，使用 AskUserQuestion 詢問：覆蓋 / 加日期後綴 / 取消
plan 格式：
# Implementation Plan: [功能名稱]
> Generated by /design on [日期]
> Plan file: plans/active/<slug>.md
> Status: PENDING APPROVAL
## Overview
<!-- 1-3 句話描述目標 -->
## ECC Resources
<!-- 本次計畫使用的 agents/skills/commands -->
| Resource | Type | Usage |
|----------|------|-------|
| tdd-guide | agent | Step 3: 撰寫測試 |
| code-reviewer | agent | Step 5: 品質審查 |
| ... | ... | ... |
## Industry & Standards Reference
| 技術決策 | 參照依據 | 類型 | 來源 |
|----------|---------|------|------|
| ... | ... | 業界標準/學術研究/標準化方案/最佳實踐 | ... |
## Implementation Steps
### Phase 1: [實作階段]
- [ ] Step 1: ...
- Agent: `planner`
- Input: ...
- Output: ...
### Phase 2: [品質保障]
- [ ] 執行 code-reviewer 審查程式碼品質
- [ ] 執行 security-reviewer 檢查安全性
- [ ] 執行 /verify 進行全面驗證
### Phase 3: [文件同步]
- [ ] 執行 /update 更新知識庫（doc-updater + learn-eval）
- [ ] 或手動執行 /update-docs + /update-codemaps
## Architecture Notes
<!-- architect 的審查結果（含文件影響評估）-->
## Risks & Mitigations
<!-- 風險評估 -->
## Acceptance Criteria
- [ ] ...
- [ ] ...
## Review Notes
<!-- 計畫品質自審的結果 -->
最後提示使用者：
plans/active/<slug>.md已生成，請確認計畫內容。 確認後可以開始實作；實作完成後執行/plan-archive歸檔。
Step 6: Worktree 隔離開發（可選）
plan 輸出後，使用 AskUserQuestion 詢問使用者：
是否要在 worktree 中進行隔離開發？
Worktree 可將實作隔離在獨立目錄，不影響主工作區。 PR merge 後 worktree 會自動回收，不需手動管理。
- 進入 worktree — 建立隔離環境，在新 session 中開發
- 不使用 — 在當前工作區直接開發
若使用者選擇「進入 worktree」：
- 從 plan slug 推導 worktree 名稱（例：
pdt-8953-url） - 呼叫
EnterWorktree(name: "<slug>") - 提示使用者：開發完成後執行
/pr，worktree 將在 session 結束時自動回收
若使用者選擇「不使用」：跳過，結束 /design 流程。