提示詞優化器 是做什麼的？
分析草稿提示詞、進行評析、匹配 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、架構性變更 | 使用藍圖技能規劃多階段工作階段 |
階段 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 偵測到，或需要使用者指定？
- 目標範圍 — 是否提及檔案、目錄或模組？
- 驗收標準 — 如何確認任務完成？
- 錯誤處理 — 是否處理邊界情況與失敗模式？
- 安全需求 — 驗證、輸入驗證、機密？
- 測試期望 — 單元測試、整合測試、端對端測試？
- 效能限制 — 負載、延遲、資源限制？
- UI/UX 需求 — 設計規格、響應式設計、無障礙（若為前端）？
- 資料庫變更 — Schema、遷移、索引（若涉及資料層）？
- 既有模式 — 需遵循的參考檔案或慣例？
- 範圍邊界 — 不應做的事？
如果遺失 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 偵測到： 含有 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%+
- 頁面在行動端與桌面端正常渲染
- 登入成功跳轉到 dashboard，失敗顯示錯誤資訊
不要做：
- 不要實作註冊頁面
- 不要實作忘記密碼功能
- 不要修改現有的路由結構
範例 2：中等程度的英文提示詞
使用者輸入：
Add a REST API endpoint for user profile updates with validation
階段 0 偵測到： 含有 Go 1.22、Chi 路由器的 go.mod
優化提示詞（完整版）：
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
…
[已截斷以利翻譯]