---
name: design
description: 開發設計 — 自動盤點 ECC 資源，透過 planner + architect 建立完整實作計畫，輸出 plan.md 供使用者確認後才進入實作。
allowed-tools: Bash, Read, Glob, Grep, Edit, Write, Agent, AskUserQuestion
argument-hint: <功能描述或需求>
---

# /design — 開發設計

接收功能需求，自動盤點可用的 ECC 資源（agents/skills/commands），建立完整實作計畫並輸出 plan.md。**不會自動執行實作，必須等使用者確認。**

## Step 1: 盤點 ECC 資源

掃描所有可用的 ECC agents、skills 和 commands，作為後續規劃的參考。

**掃描方式：**

1. 列出所有可用的 agent types（從 Agent tool 的 subagent_type 列表），包括 v1.8 新增的 `harness-optimizer`（harness 設定優化）和 `loop-operator`（自主迴圈監控）
2. 列出所有可用的 skills（從 system-reminder 中的 skill 列表）
3. 列出所有可用的 commands（從 `~/.claude/commands/` 和 plugin commands），包括 v1.8 新增的 `/harness-audit`、`/quality-gate`、`/loop-start`
4. 根據使用者的需求（`$ARGUMENTS`），篩選出**相關的資源**

**輸出：** 一份簡潔的資源清單，標記每個資源與當前需求的關聯程度（高/中/低）。

## Step 2: 複雜度評估

根據需求規模，選擇執行路徑：

| 複雜度 | 判斷標準 | 執行路徑 |
|--------|---------|---------|
| **低** | 單一檔案、不涉及架構變更（例：更新 README、加 badge、改設定） | 跳過 Step 4（architect），直接 Step 3 → Step 5 |
| **中等以上** | 跨檔案或有架構影響 | 完整流程 Step 3 → Step 4 → Step 5 |

如果需求過於模糊無法判斷複雜度，使用 AskUserQuestion 請使用者補充具體資訊。

> 無論走哪條路徑，都會輸出 plan.md。

## Step 3: planner — 建立實作計畫

使用 **planner** agent 建立詳細的實作計畫。

```
Agent(subagent_type="everything-claude-code:planner")
```

**輸入 context：**

- 使用者的需求描述（`$ARGUMENTS` + 對話脈絡）
- Step 1 盤點的 ECC 資源清單
- 當前專案結構（透過 `ls`、`git status` 等了解）

**計畫須包含：**

1. **需求拆解** — 將需求分解為可執行的子任務
2. **技術方案** — 每個子任務的實作方式
3. **業界實踐與標準化方案參照** — 每個技術方案須附上依據
   - 是否有業界標準或慣例（RFC、W3C、OWASP、12-Factor 等）
   - 是否有學術研究支撐（論文、benchmarks）
   - 是否有成熟的標準化解決方案（官方 SDK、知名 library 的 canonical pattern）
   - 若無直接標準，說明為何採用自訂方案，並引述最接近的參考
4. **ECC 資源整合** — 明確指出每個步驟應使用哪個 agent/skill/command。**ECC 資源分配須經盤點確認** — 不可假設資源可用，須回溯 Step 1 的盤點結果
   - 例：「Step 3: 使用 tdd-guide agent 撰寫測試」
   - 例：「Step 5: 使用 /code-review 進行品質審查」
5. **依賴關係** — 哪些步驟必須按順序執行、哪些可以並行
6. **風險評估** — 潛在的技術風險和對策
7. **驗收標準** — 怎樣算完成

## Step 4: architect — 架構設計審查

使用 **architect** agent 審查 Step 3 的計畫。

```
Agent(subagent_type="everything-claude-code:architect")
```

**審查重點：**

- 架構是否合理、可擴展
- 是否有更簡單的替代方案
- 與現有程式碼的相容性
- 效能和安全性考量
- **業界/學術參照的可靠性** — 引用的標準是否適用於當前情境、是否為最新版本、有無更好的標準化方案被遺漏
- ECC 資源的選用是否恰當 — **須對照 Step 1 盤點結果，確認所選 agent/skill 在當前 session 可用**
- 文件影響評估：實作後需要新增或更新哪些文件（README、API docs、CODEMAPS），列入 plan.md 待辦

**如果有重大架構建議：** 回饋給 planner 調整計畫（最多迭代 2 次）。

## Step 5: 輸出 plan.md

將最終計畫寫入檔案前，先對照以下檢查清單確認計畫品質：

| 維度 | 通過標準 |
|------|---------|
| 完整性 | 每個需求都有對應的實作步驟 |
| 可執行性 | 每個步驟有明確的檔案路徑和具體動作 |
| 依賴正確性 | 步驟間依賴無環且順序合理 |
| 粒度適當 | 每個步驟 1-3 個具體動作 |
| ECC 資源合理 | 每個 agent/skill 在其設計用途內使用 |
| 驗收可測 | 每個驗收標準都可客觀驗證 |
| 業界/學術支撐 | 每個技術方案都有明確的業界標準、學術研究或標準化方案參照 |
| 實作後工具 | plan.md 的步驟中包含實作後的品質保障（code-reviewer、/update、/verify 等） |
| Eval 基線 | 若涉及行為變更，計畫中包含 eval 基線建立與回歸驗證步驟（參考 `/quality-gate`） |

如果發現問題，直接修正計畫內容。

**輸出路徑：** 專案根目錄的 `plan.md`（如果已存在，使用 AskUserQuestion 詢問是否覆蓋）

**plan.md 格式：**

```markdown
# Implementation Plan: [功能名稱]

> Generated by /design on [日期]
> 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
<!-- 計畫品質自審的結果 -->
```

**最後提示使用者：**

> plan.md 已生成，請確認計畫內容。確認後可以開始實作。