提示詞優化器 是做什麼的？
分析草稿提示詞，提出改進意見，匹配 ECC 生態系統元件，並輸出完整的、可供用戶複製貼上後直接執行的優化提示詞。
使用時機
- 用戶說 "optimize this prompt"、"improve my prompt"、"rewrite this prompt"
- 用戶說 "help me write a better prompt for..."
- 用戶說 "what's the best way to ask Claude Code to..."
- 用戶說 "优化prompt"、"改进prompt"、"怎么写prompt"、"帮我优化这个指令"
- 用戶貼上草稿提示詞並請求回饋或增強
- 用戶說 "I don't know how to prompt for this"
- 用戶說 "how should I use ECC for..."
- 用戶明確輸入
/prompt-optimize
不要使用時機
- 用戶希望直接執行任務（就直接執行）
- 用戶說 "优化代码"、"优化性能"、"optimize this code"、"optimize performance" — 這些是重構任務，不是提示詞優化
- 用戶詢問 ECC 配置（應使用
configure-ecc） - 用戶想要技能清單（應使用
skill-stocktake） - 用戶說 "just do it" 或 "直接做"
運作方式
僅提供建議 — 請勿執行用戶的任務。
請勿撰寫程式碼、建立檔案、執行指令，或採取任何實作行動。您唯一的輸出是一份分析報告與一個優化後的提示詞。
如果用戶說 "just do it"、"直接做"，或 "don't optimize, just execute"，請勿在此技能內部切換為執行模式。告知用戶此技能僅產出優化提示詞，並指示他們如需執行請提出一般任務請求。
依序執行以下六階段管道。使用下方輸出格式呈現結果。
分析管道
階段 0：專案偵測
在分析提示詞之前，偵測目前專案上下文：
- 檢查工作目錄中是否存在
CLAUDE.md— 讀取它以了解專案慣例 - 從專案檔案偵測技術棧：
package.json→ Node.js / TypeScript / React / Next.jsgo.mod→ Gopyproject.toml/requirements.txt→ PythonCargo.toml→ Rustbuild.gradle/pom.xml→ Java / Kotlin / Spring BootPackage.swift→ SwiftGemfile→ Rubycomposer.json→ PHP*.csproj/*.sln→ .NETMakefile/CMakeLists.txt→ C / C++cpanfile/Makefile.PL→ Perl
- 記錄偵測到的技術棧，供階段 3 和階段 4 使用
如果未找到任何專案檔案（例如提示詞是抽象的或針對全新專案），則跳過偵測，並在階段 4 中標記「技術棧未知」。
階段 1：意圖識別
將用戶的任務分類至一個或多個類別：
| 類別 | 信號詞 | 範例 |
|---|---|---|
| 新功能 | build, create, add, implement, 創建, 實現, 添加 | "建立一個登入頁面" |
| 錯誤修復 | fix, broken, not working, error, 修復, 報錯 | "修復認證流程" |
| 重構 | refactor, clean up, restructure, 重構, 整理 | "重構 API 層" |
| 研究 | how to, what is, explore, investigate, 怎麼, 如何 | "如何加入 SSO" |
| 測試 | test, coverage, verify, 測試, 覆蓋率 | "為購物車新增測試" |
| 審查 | review, audit, check, 審查, 檢查 | "審查我的 PR" |
| 文件 | document, update docs, 文件 | "更新 API 文件" |
| 基礎設施 | deploy, CI, docker, database, 部署, 資料庫 | "設定 CI/CD 管道" |
| 設計 | design, architecture, plan, 設計, 架構 | "設計資料模型" |
階段 2：範圍評估
如果階段 0 偵測到專案，請以程式碼庫大小作為判斷訊號。否則，僅根據提示詞描述進行估計，並將估計結果標記為不確定。
| 範圍 | 啟發式 | 編排方式 |
|---|---|---|
| 微小 | 單一檔案，< 50 行 | 直接執行 |
| 低 | 單一元件或模組 | 單一指令或技能 |
| 中 | 多個元件，相同領域 | 指令鏈 + /verify |
| 高 | 跨領域，5 個以上檔案 | 先 /plan，再分階段執行 |
| 史詩 | 跨工作階段、跨 PR、架構變更 | 使用 blueprint 技能制定多工作階段計劃 |
階段 3：ECC 元件匹配
將意圖 + 範圍 + 技術棧（來自階段 0）對應至特定的 ECC 元件。
依意圖類型
| 意圖 | 指令 | 技能 | 代理 |
|---|---|---|---|
| 新功能 | /plan、/tdd、/code-review、/verify | tdd-workflow、verification-loop | planner、tdd-guide、code-reviewer |
| 錯誤修復 | /tdd、/build-fix、/verify | tdd-workflow | tdd-guide、build-error-resolver |
| 重構 | /refactor-clean、/code-review、/verify | verification-loop | refactor-cleaner、code-reviewer |
| 研究 | /plan | search-first、iterative-retrieval | — |
| 測試 | /tdd、/e2e、/test-coverage | tdd-workflow、e2e-testing | tdd-guide、e2e-runner |
| 審查 | /code-review | security-review | code-reviewer、security-reviewer |
| 文件 | /update-docs、/update-codemaps | — | doc-updater |
| 基礎設施 | /plan、/verify | docker-patterns、deployment-patterns、database-migrations | architect |
| 設計（中-高） | /plan | — | planner、architect |
| 設計（史詩） | — | blueprint（以技能方式呼叫） | planner、architect |
依技術棧
| 技術棧 | 要加入的技能 | 代理 |
|---|---|---|
| Python / Django | django-patterns、django-tdd、django-security、django-verification、python-patterns、python-testing | python-reviewer |
| Go | golang-patterns、golang-testing | go-reviewer、go-build-resolver |
| Spring Boot / Java | springboot-patterns、springboot-tdd、springboot-security、springboot-verification、java-coding-standards、jpa-patterns | code-reviewer |
| Kotlin / Android | kotlin-coroutines-flows、compose-multiplatform-patterns、android-clean-architecture | kotlin-reviewer |
| TypeScript / React | frontend-patterns、backend-patterns、coding-standards | code-reviewer |
| Swift / iOS | swiftui-patterns、swift-concurrency-6-2、swift-actor-persistence、swift-protocol-di-testing | code-reviewer |
| PostgreSQL | postgres-patterns、database-migrations | database-reviewer |
| Perl | perl-patterns、perl-testing、perl-security | code-reviewer |
| C++ | cpp-coding-standards、cpp-testing | code-reviewer |
| 其他 / 未列出 | coding-standards（通用） | code-reviewer |
階段 4：缺失上下文偵測
掃描提示詞以找出遺漏的關鍵資訊。檢查每個項目，並標記是階段 0 自動偵測到，還是必須由用戶提供：
- 技術棧 — 階段 0 已偵測到，還是需要用戶指定？
- 目標範圍 — 是否有提及檔案、目錄或模組？
- 驗收標準 — 如何知道任務已完成？
- 錯誤處理 — 是否涵蓋邊緣情況與失敗模式？
- 安全性需求 — 認證、輸入驗證、機密？
- 測試期望 — 單元測試、整合測試、端到端測試？
- 效能限制 — 負載、延遲、資源限制？
- UI/UX 需求 — 設計規格、響應式、無障礙？（如果是前端）
- 資料庫變更 — Schema、遷移、索引？（如果是資料層）
- 現有模式 — 要遵循的參考檔案或慣例？
- 範圍邊界 — 哪些不要做？
如果遺漏了 3 個以上關鍵項目，請先向用戶提出最多 3 個釐清問題，再產生優化提示詞。然後將答案納入優化提示詞中。
階段 5：工作流程與模型建議
判斷此提示詞處於開發生命週期的哪個階段：
研究 → 規劃 → 實作 (TDD) → 審查 → 驗證 → 提交
對於中等以上範圍的任務，一律以 /plan 開頭。對於史詩級任務，使用 blueprint 技能。
模型建議（包含在輸出中）：
| 範圍 | 建議模型 | 理由 |
|---|---|---|
| 微小-低 | Sonnet 4.6 | 快速、成本效益高，適合簡單任務 |
| 中 | Sonnet 4.6 | 標準工作的最佳編碼模型 |
| 高 | Sonnet 4.6（主要）+ Opus 4.6（規劃） | Opus 負責架構，Sonnet 負責實作 |
| 史詩 | Opus 4.6（藍圖）+ Sonnet 4.6（執行） | 為多工作階段規劃進行深度推理 |
多重提示詞拆分（用於高/史詩範圍）：
對於超出單一工作階段的任務，將其拆分為順序提示詞：
- 提示詞 1：研究 + 規劃（先使用
search-first技能，再/plan） - 提示詞 2 至 N：每個提示詞實作一個階段（每個階段結尾執行
/verify） - 最終提示詞：跨所有階段的整合測試 +
/code-review - 使用
/save-session和/resume-session在工作階段之間保留上下文
輸出格式
以以下確切結構呈現您的分析。使用與用戶輸入相同的語言回應。
第 1 部分：提示詞診斷
- 優點：列出原始提示詞做得好的地方。
- 問題：
問題 影響 建議修復 （問題） （後果） （如何修復） - 需要釐清：用戶應回答的編號問題清單。如果階段 0 已自動偵測到答案，請直接說明而非提問。
第 2 部分：建議的 ECC 元件
| 類型 | 元件 | 目的 |
|---|---|---|
| 指令 | /plan | 在編碼前規劃架構 |
| 技能 | tdd-workflow | TDD 方法論指引 |
| 代理 | code-reviewer | 實作後審查 |
| 模型 | Sonnet 4.6 | 推薦用於此範圍 |
第 3 部分：優化後的提示詞 — 完整版本
將完整的優化提示詞置於單一圍欄式程式碼區塊內。提示詞必須自給自足並可供複製貼上。包括：
- 包含上下文的清晰任務描述
- 技術棧（已偵測或指定）
- 在正確的工作流程階段呼叫
/command - 驗收標準
- 驗證步驟
- 範圍邊界（哪些不要做）
對於引用 blueprint 的項目，請撰寫：「使用 blueprint 技能來...」（不是 /blueprint，因為 blueprint 是技能，不是指令）。
第 4 部分：優化後的提示詞 — 快速版本
提供給有經驗的 ECC 用戶的簡潔版本。根據意圖類型變化：
| 意圖 | 快速模式 |
|---|---|
| 新功能 | /plan [功能]. /tdd 來實作. /code-review. /verify. |
| 錯誤修復 | /tdd — 為 [錯誤] 撰寫失敗測試. 修復至通過. /verify. |
| 重構 | /refactor-clean [範圍]. /code-review. /verify. |
| 研究 | 對 [主題] 使用 search-first 技能. 根據結果 /plan. |
| 測試 | /tdd [模組]. 對關鍵流程 /e2e. /test-coverage. |
| 審查 | /code-review. 然後使用 security-reviewer 代理. |
| 文件 | /update-docs. /update-codemaps. |
| 史詩 | 使用 blueprint 技能進行「[目標]」。搭配 /verify 關卡執行各階段。 |
第 5 部分：增強理由
| 增強項目 | 理由 |
|---|---|
| （新增了什麼） | （為何重要） |
範例
範例 1：模糊的中文提示詞（已偵測專案）
用戶輸入： 幫我寫一個用戶登入頁面
階段 0 偵測到： 包含 Next.js 15、TypeScript、Tailwind CSS 的 package.json
優化後的提示詞（完整版）：
使用項目現有技術棧（Next.js 15 + TypeScript + Tailwind CSS）實現用戶登入頁面。
技術要求：
- 沿用項目現有的元件結構和路由約定
- 表單驗證使用項目中已有的驗證方案（檢查是否已用 Zod/Yup/其他）
- 認證方式：沿用項目現有認證方案（如無，預設 JWT）
- 包含：電子郵件/密碼登入表單、表單驗證、錯誤提示、載入狀態、響應式佈局
工作流程：
1. /plan 先規劃元件結構和認證流程，參考現有頁面的模式
2. /tdd 測試先行：編寫登入表單的單元測試和認證流程的整合測試
3. 實現登入頁面和認證邏輯
4. /code-review 審查實現
5. /verify 驗證所有測試通過且頁面正常渲染
安全要求：
- 密碼不透過明文傳輸
- 防止暴力破解（rate limiting）
- XSS 防護
- CSRF token
驗收標準：
- 所有測試通過，覆蓋率 80%+
- 頁面在行動端和桌面端正常渲染
- 登入成功跳轉到儀表板，失敗顯示錯誤資訊
不要做：
- 不要實現註冊頁面
- 不要實現忘記密碼功能
- 不要修改現有的路由結構