Prompt 優化器 是做什麼的？
分析草稿提示詞，提供評論，匹配 ECC 生態系統元件， 並產出一個完整的優化提示詞，使用者可以直接複製貼上執行。
使用時機
- 使用者說「優化這個提示詞」、「改進我的提示詞」、「改寫這個提示詞」
- 使用者說「幫我寫一個更好的提示詞來...」
- 使用者說「讓 Claude Code 做... 的最佳方法是？」
- 使用者說「優化 prompt」、「改進 prompt」、「怎麼寫 prompt」、「幫我優化這個指令」
- 使用者貼上草稿提示詞並要求回饋或增強
- 使用者說「我不知道怎麼為這個寫提示詞」
- 使用者說「我該怎麼用 ECC 做...」
- 使用者明確呼叫
/prompt-optimize
不應使用的情況
- 使用者希望直接完成任務（只需執行）
- 使用者說「優化程式碼」、「優化效能」、「optimize this code」、「optimize performance」——這些是重構任務，不是提示詞優化
- 使用者詢問 ECC 設定（應改用
configure-ecc） - 使用者想要技能清單（應改用
skill-stocktake） - 使用者說「直接做」或「直接做」
運作方式
僅提供建議 — 請勿執行使用者的任務。
不要寫程式碼、建立檔案、執行命令或採取任何實作行動。 您的唯一輸出是分析加上優化後的提示詞。
如果使用者說「直接做」、「直接做」或「不用優化，直接執行」， 請勿在此技能內切換為實作模式。告訴使用者此技能只產生優化提示詞， 並指示他們如果需要執行，請提出一般的任務要求。
依次執行此 6 階段流程。使用下方「輸出格式」呈現結果。
分析流程
階段 0：專案偵測
在分析提示詞之前，先偵測當前專案脈絡：
- 檢查工作目錄中是否存在
CLAUDE.md— 讀取其專案慣例 - 從專案檔案偵測技術棧：
package.json→ Node.js / TypeScript / React / Next.jsgo.mod→ Gopyproject.toml/requirements.txt→ PythonCargo.toml→ Rustbuild.gradle/pom.xml→ Java / Kotlin（然後檢查建構檔中是否有quarkus→ Quarkus，或spring-boot→ Spring Boot）Package.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 | java-reviewer |
| Quarkus / Java | quarkus-patterns, quarkus-tdd, quarkus-security, quarkus-verification, java-coding-standards, jpa-patterns | java-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 偵測到，或需使用者指定？
- 目標範圍 — 有提到檔案、目錄或模組嗎？
- 驗收標準 — 如何知道任務完成？
- 錯誤處理 — 是否涵蓋邊緣情況與失敗模式？
- 安全需求 — 認證、輸入驗證、機密？
- 測試期望 — 單元測試、整合測試、E2E？
- 效能限制 — 負載、延遲、資源限制？
- UI/UX 需求 — 設計規範、響應式設計、無障礙？(如果是前端)
- 資料庫變更 — 綱要、遷移、索引？(如果是資料層)
- 現有模式 — 需遵循的參考檔案或慣例？
- 範圍邊界 — 什麼不該做？
如果遺漏 3 個以上關鍵項目，在產生優化提示詞前，先向使用者提出最多 3 個澄清問題。然後將答案納入優化提示詞中。
階段 5：工作流程與模型建議
確定此提示詞在開發生命週期中的位置：
研究 → 規劃 → 實作 (TDD) → 審查 → 驗證 → 提交
對於「中」以上任務，一律先使用 /plan。對於「史詩級」任務，使用 bluePrint 技能。
模型建議（包含在輸出中）：
| 範圍 | 建議模型 | 理由 |
|---|---|---|
| 簡單-低 | Sonnet 5 | 快速、經濟實惠，適用於簡單任務 |
| 中 | Sonnet 5 | 標準工作的最佳編碼模型 |
| 高 | Sonnet 5（主要）+ Opus 5（規劃） | Opus 負責架構，Sonnet 負責實作 |
| 史詩級 | Opus 5（規劃）+ Sonnet 5（執行） | 多階段規劃需深度推理 |
多重提示詞拆分（適用於高/史詩級範圍）：
對於超出單一工作階段的任務，拆分成連續的提示詞：
- 提示詞 1：研究 + 規劃（先使用 search-first 技能，然後 /plan）
- 提示詞 2-N：每個提示詞實作一個階段（每個以 /verify 結尾）
- 最後提示詞：整合測試 + 跨所有階段的 /code-review
- 使用 /save-session 與 /resume-session 在工作階段之間保留脈絡
輸出格式
以以下結構呈現您的分析。請以與使用者輸入相同的語言回應。
區段 1：提示詞診斷
優點： 列出原始提示詞做得好的地方。
問題：
| 問題 | 影響 | 建議修正 |
|---|---|---|
| (問題) | (後果) | (如何修正) |
需要釐清： 使用者應回答的問題編號清單。 如果階段 0 已自動偵測到答案，請直接說明，而非提問。
區段 2：建議的 ECC 元件
| 類型 | 元件 | 用途 |
|---|---|---|
| 命令 | /plan | 在編碼前規劃架構 |
| 技能 | tdd-workflow | TDD 方法論指引 |
| 代理 | code-reviewer | 實作後審查 |
| 模型 | Sonnet 5 | 建議用於此範圍 |
區段 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：增強理由
| 增強 | 理由 |
|---|---|
| (新增了什麼) | (為什麼重要) |
頁尾
不是您需要的？告訴我要調整什麼，或者如果您需要執行而非提示詞優化，請提出一般的任務要求。
範例
觸發範例
- 「為 ECC 優化此提示詞」
- 「改寫此提示詞，讓 Claude Code 使用正確的命令」
- 「幫我優化這個指令」
- 「我該怎麼為此任務向 ECC 下提示詞？」
範例 1：模糊的中文提示詞（已偵測到專案）
使用者輸入：
幫我寫一個使用者登入頁面
階段 0 偵測到： package.json 中有 Next.js 15、TypeScript、Tailwind CSS
優化提示詞（完整版）：
使用專案現有技術棧（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%+
- 頁面在行動裝置和桌面上正常渲染
- 登入成功跳轉到 dashboard，失敗顯示錯誤訊息
不要做：
- 不要實作註冊頁面
- 不要實作忘記密碼功能
- 不要修改現有的路由結構
範例 2：中等英文提示詞
使用者輸入：
Add a REST API endpoint for user profile updates with validation
階段 0 偵測到： go.mod 中有 Go 1.22、Chi router
優化提示詞（完整版）：
Add a REST API endpoint for user profile updates (PATCH /api/users/:id).
Tech stack: Go 1.22 + Chi router (detected from project)
Requirements:
- PATCH /api/users/:id — partial update of user profile
- Input validation for fields: name, email, avatar_url, bio
- Auth: require valid token, users can only update own profile
- Return 200 with updated user on success
- Return 400 with validation errors on invalid input
- Return 401/403 for auth failures
- Follow existing API patterns in the codebase
Workflow:
1. /plan the endpoint structure, middleware chain, and validation logic
2. /tdd — write table-driven tests for success, validation failure, auth failure, not-found
3. Implement following existing handler patterns
4. /go-review
5. /verify — run full test suite, confirm no regressions
Do not:
- Modify existing endpoints
- Change the database schema (use existing user table)
- Add new dependencies without checking existing ones first (use search-first skill)
範例 3：史詩級專案
使用者輸入：
Migrate our monolith to microservices
優化提示詞（完整版）：
Use the blueprint skill to plan: "Migrate monolith to microservices architecture"
Before executing, answer these questions in the blueprint:
1. Which domain boundaries exist in the current monolith?
2. Which service should be extracted first (lowest coupling)?
3. Communication pattern: REST APIs, gRPC, or event-driven (Kafka/RabbitMQ)?
4. Database strategy: shared DB initially or database-per-service from start?
5. Deployment target: Kubernetes, Docker Compose, or serverless?
The blueprint should produce phases like:
- Phase 1: Identify service boundaries and create domain map
- Phase 2: Set up infrastructure (API gateway, service mesh, CI/CD per service)
- Phase 3: Extract first service (strangler fig pattern)
- Phase 4: Verify with integration tests, then extract next service
- Phase N: Decommission monolith
Each phase = 1 PR, with /verify gates between phases.
Use /save-session between phases