/design — 開發設計

接收功能需求，自動盤點可用的 ECC 資源（agents/skills/commands），建立完整實作計畫並輸出至 plans/active/.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/.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-url
Stripe 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 流程。