Back to Details

design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/design — 開發設計

/design — Development & Design

接收功能需求，自動盤點可用的 ECC 資源（agents/skills/commands），建立完整實作計畫並輸出 plan.md。不會自動執行實作，必須等使用者確認。
Receive functional requirements, automatically inventory available ECC resources (agents/skills/commands), build a complete implementation plan and output plan.md. It will not execute the implementation automatically, and must wait for user confirmation.

Step 1: 盤點 ECC 資源

Step 1: Inventory ECC Resources

掃描所有可用的 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
    ），篩選出相關的資源
輸出： 一份簡潔的資源清單，標記每個資源與當前需求的關聯程度（高/中/低）。
Scan all available ECC agents, skills and commands as references for subsequent planning.
Scanning method:
  1. List all available agent types (from the subagent_type list of the Agent tool), including the 
    harness-optimizer
    (harness configuration optimization) and 
    loop-operator
    (autonomous loop monitoring) added in v1.8
  2. List all available skills (from the skill list in system-reminder)
  3. List all available commands (from 
    ~/.claude/commands/
    and plugin commands), including 
    /harness-audit
    , 
    /quality-gate
    , 
    /loop-start
    added in v1.8
  4. Filter out relevant resources according to the user's requirements (
    $ARGUMENTS
    )
Output: A concise resource list, marking the relevance level (high/medium/low) of each resource to the current requirement.

Step 2: 複雜度評估

Step 2: Complexity Assessment

根據需求規模，選擇執行路徑：
複雜度判斷標準執行路徑
低單一檔案、不涉及架構變更（例：更新 README、加 badge、改設定）跳過 Step 4（architect），直接 Step 3 → Step 5
中等以上跨檔案或有架構影響完整流程 Step 3 → Step 4 → Step 5
如果需求過於模糊無法判斷複雜度，使用 AskUserQuestion 請使用者補充具體資訊。
無論走哪條路徑，都會輸出 plan.md。
Select the execution path according to the scale of the requirement:
ComplexityJudgment CriteriaExecution Path
LowSingle file, no architecture changes involved (e.g. update README, add badge, modify configuration)Skip Step 4 (architect), go directly from Step 3 → Step 5
Medium and aboveCross-file or has architecture impactComplete process Step 3 → Step 4 → Step 5
If the requirement is too vague to judge the complexity, use AskUserQuestion to ask the user to supplement specific information.
No matter which path is taken, plan.md will be output.

Step 3: planner — 建立實作計畫

Step 3: planner — Build Implementation Plan

使用 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. 驗收標準 — 怎樣算完成
Use the planner agent to build a detailed implementation plan.
Agent(subagent_type="everything-claude-code:planner")
Input context:
  • User's requirement description (
    $ARGUMENTS
    + conversation context)
  • ECC resource list inventoried in Step 1
  • Current project structure (understood through 
    ls
    , 
    git status
    , etc.)
The plan must include:
  1. Requirement decomposition — Decompose the requirement into executable subtasks
  2. Technical solution — Implementation method for each subtask
  3. Industry practice and standardization solution reference — Each technical solution must be attached with a basis
    • Whether there are industry standards or conventions (RFC, W3C, OWASP, 12-Factor, etc.)
    • Whether there is academic research support (papers, benchmarks)
    • Whether there are mature standardized solutions (official SDK, canonical pattern of well-known libraries)
    • If there is no direct standard, explain why the custom solution is adopted, and quote the closest reference
  4. ECC resource integration — Clearly indicate which agent/skill/command should be used in each step. ECC resource allocation must be confirmed through inventory — Do not assume resources are available, and must trace back to the inventory results of Step 1
    • Example: "Step 3: Use tdd-guide agent to write tests"
    • Example: "Step 5: Use /code-review for quality review"
  5. Dependency relationship — Which steps must be executed in sequence and which can be parallelized
  6. Risk assessment — Potential technical risks and countermeasures
  7. Acceptance criteria — What counts as completion

Step 4: architect — 架構設計審查

Step 4: architect — Architecture Design Review

使用 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 次）。
Use the architect agent to review the plan from Step 3.
Agent(subagent_type="everything-claude-code:architect")
Review focus:
  • Whether the architecture is reasonable and scalable
  • Whether there is a simpler alternative
  • Compatibility with existing code
  • Performance and security considerations
  • Reliability of industry/academic references — Whether the cited standards are applicable to the current scenario, whether they are the latest version, and whether there are better standardized solutions omitted
  • Whether the selection of ECC resources is appropriate — Must compare with the inventory results of Step 1 to confirm that the selected agent/skill is available in the current session
  • Document impact assessment: Which documents (README, API docs, CODEMAPS) need to be added or updated after implementation, and be included in the plan.md to-do list
If there are major architecture suggestions: Feed back to the planner to adjust the plan (up to 2 iterations).

Step 5: 輸出 plan.md

Step 5: Output plan.md

將最終計畫寫入檔案前，先對照以下檢查清單確認計畫品質：
維度通過標準
完整性每個需求都有對應的實作步驟
可執行性每個步驟有明確的檔案路徑和具體動作
依賴正確性步驟間依賴無環且順序合理
粒度適當每個步驟 1-3 個具體動作
ECC 資源合理每個 agent/skill 在其設計用途內使用
驗收可測每個驗收標準都可客觀驗證
業界/學術支撐每個技術方案都有明確的業界標準、學術研究或標準化方案參照
實作後工具plan.md 的步驟中包含實作後的品質保障（code-reviewer、/update、/verify 等）
Eval 基線若涉及行為變更，計畫中包含 eval 基線建立與回歸驗證步驟（參考 
/quality-gate
）
如果發現問題，直接修正計畫內容。
輸出路徑： 專案根目錄的 
plan.md
（如果已存在，使用 AskUserQuestion 詢問是否覆蓋）
plan.md 格式：
markdown
undefined
Before writing the final plan to the file, first check the plan quality against the following checklist:
DimensionPassing Standard
CompletenessEach requirement has corresponding implementation steps
ExecutabilityEach step has a clear file path and specific actions
Dependency correctnessDependencies between steps have no loops and the order is reasonable
Appropriate granularityEach step has 1-3 specific actions
Reasonable ECC resourcesEach agent/skill is used within its designed purpose
Testable acceptanceEach acceptance criterion can be objectively verified
Industry/academic supportEach technical solution has clear industry standards, academic research or standardized solution references
Post-implementation toolsThe steps of plan.md include post-implementation quality assurance (code-reviewer, /update, /verify, etc.)
Eval baselineIf behavioral changes are involved, the plan includes eval baseline establishment and regression verification steps (refer to 
/quality-gate
)
If problems are found, directly modify the plan content.
Output path: 
plan.md
in the project root directory (if it already exists, use AskUserQuestion to ask whether to overwrite)
plan.md format:
markdown
undefined

Implementation Plan: [功能名稱]

Implementation Plan: [Function Name]

Generated by /design on [日期] Status: PENDING APPROVAL
Generated by /design on [Date] Status: PENDING APPROVAL

Overview

Overview

<!-- 1-3 句話描述目標 -->
<!-- 1-3 sentences describing the goal -->

ECC Resources

ECC Resources

<!-- 本次計畫使用的 agents/skills/commands -->
ResourceTypeUsage
tdd-guideagentStep 3: 撰寫測試
code-revieweragentStep 5: 品質審查
.........
<!-- agents/skills/commands used in this plan -->
ResourceTypeUsage
tdd-guideagentStep 3: Write tests
code-revieweragentStep 5: Quality review
.........

Industry & Standards Reference

Industry & Standards Reference

技術決策參照依據類型來源
......業界標準/學術研究/標準化方案/最佳實踐...
Technical DecisionReference BasisTypeSource
......Industry Standard/Academic Research/Standardized Solution/Best Practice...

Implementation Steps

Implementation Steps

Phase 1: [實作階段]

Phase 1: [Implementation Phase]

  • Step 1: ...
    • Agent: 
      planner
    • Input: ...
    • Output: ...
  • Step 1: ...
    • Agent: 
      planner
    • Input: ...
    • Output: ...

Phase 2: [品質保障]

Phase 2: [Quality Assurance]

  • 執行 code-reviewer 審查程式碼品質
  • 執行 security-reviewer 檢查安全性
  • 執行 /verify 進行全面驗證
  • Execute code-reviewer to review code quality
  • Execute security-reviewer to check security
  • Execute /verify for comprehensive verification

Phase 3: [文件同步]

Phase 3: [Document Synchronization]

  • 執行 /update 更新知識庫（doc-updater + learn-eval）
  • 或手動執行 /update-docs + /update-codemaps
  • Execute /update to update the knowledge base (doc-updater + learn-eval)
  • Or manually execute /update-docs + /update-codemaps

Architecture Notes

Architecture Notes

<!-- architect 的審查結果（含文件影響評估）-->
<!-- architect's review results (including document impact assessment) -->

Risks & Mitigations

Risks & Mitigations

<!-- 風險評估 -->
<!-- Risk assessment -->

Acceptance Criteria

Acceptance Criteria

  • ...
  • ...
  • ...
  • ...

Review Notes

Review Notes

<!-- 計畫品質自審的結果 --> 

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

> plan.md 已生成，請確認計畫內容。確認後可以開始實作。
<!-- Results of plan quality self-review --> 

**Final prompt to user:**

> plan.md has been generated, please confirm the plan content. You can start implementation after confirmation.