prompt-optimizer

Prompt Optimizer

分析草稿提示詞，提出批評，比對 ECC 生態系統元件，並輸出完整的優化提示詞，讓使用者可以直接貼上執行。

使用時機

• 使用者說「優化這個 prompt」、「改進我的 prompt」、「改寫這個 prompt」
• 使用者說「幫我想一個更好的 prompt 來...」
• 使用者說「最好的方式是什麼來讓 Claude Code 做...」
• 使用者說「優化 prompt」、「改進 prompt」、「怎麼寫 prompt」、「幫我優化這個指令」
• 使用者貼上草稿提示詞並要求回饋或改進
• 使用者說「我不知道怎麼為這個寫 prompt」
• 使用者說「我該怎麼用 ECC 來做...」
• 使用者明確呼叫 /prompt-optimize

不使用時機

• 使用者希望直接執行任務（直接執行即可）
• 使用者說「優化程式碼」、「優化性能」、"optimize this code"、"optimize performance"——這些是重構任務，非提示詞優化
• 使用者詢問 ECC 配置（請改用 configure-ecc）
• 使用者想要技能清單（請改用 skill-stocktake）
• 使用者說「直接做」或 "just do it"

運作方式

僅提供建議——不要執行使用者的任務。

不要寫程式碼、建立檔案、執行指令，或採取任何實作行動。你唯一的輸出是分析加上優化後的提示詞。

如果使用者說「直接做」、"just do it" 或「不要優化，直接執行」，不要在此技能內切換到實作模式。告訴使用者此技能只產出優化提示詞，並指示他們如果希望執行任務，請提出一般的任務請求。

依序執行以下 6 階段流程。使用下方的輸出格式呈現結果。

分析流程

階段 0：專案偵測

在分析提示詞之前，偵測當前專案上下文：

1. 檢查工作目錄中是否存在 CLAUDE.md——讀取它以了解專案慣例
2. 從專案檔案偵測技術棧：
   • package.json → Node.js / TypeScript / React / Next.js
   • go.mod → Go
   • pyproject.toml / requirements.txt → Python
   • Cargo.toml → Rust
   • build.gradle / pom.xml → Java / Kotlin（然後檢查建置檔中是否有 quarkus → Quarkus，或 spring-boot → Spring Boot）
   • Package.swift → Swift
   • Gemfile → Ruby
   • composer.json → PHP
   • *.csproj / *.sln → .NET
   • Makefile / CMakeLists.txt → C / C++
   • cpanfile / Makefile.PL → Perl
3. 記錄偵測到的技術棧，供階段 3 和階段 4 使用

如果找不到專案檔案（例如提示詞是抽象的或針對新專案），則跳過偵測並在階段 4 標記「技術棧未知」。

階段 1：意圖偵測

將使用者的任務分類到一個或多個類別：

類別	信號詞	範例
新功能	build, create, add, implement, 創建, 實現, 添加	"建立登入頁面"
Bug 修復	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 偵測到專案，使用程式碼庫大小作為信號。否則，僅從提示詞描述估算，並將估算標記為不確定。

範圍	啟發式	編排方式
TRIVIAL	單一檔案，< 50 行	直接執行
LOW	單一元件或模組	單一指令或技能
MEDIUM	多個元件，相同領域	指令鏈 + /verify
HIGH	跨領域，5 個以上檔案	先 /plan，再分階段執行
EPIC	多個工作階段、多個 PR、架構性轉變	使用 blueprint 技能進行多階段規劃

階段 3：ECC 元件比對

將意圖 + 範圍 + 技術棧（來自階段 0）對應到特定的 ECC 元件。

依意圖類型

意圖	指令	技能	代理
新功能	/plan, /tdd, /code-review, /verify	tdd-workflow, verification-loop	planner, tdd-guide, code-reviewer
Bug 修復	/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
設計（MEDIUM-HIGH）	/plan	—	planner, architect
設計（EPIC）	—	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 需求——設計規格、響應式、無障礙？（如果是前端）
• [ ] 資料庫變更——綱要、遷移、索引？（如果是資料層）
• [ ] 現有模式——要遵循的參考檔案或慣例？
• [ ] 範圍邊界——不要做什麼？

如果遺漏 3 個以上關鍵項目，在產生優化提示詞之前，先向使用者提出最多 3 個澄清問題。然後將答案納入優化提示詞中。

階段 5：工作流程與模型建議

判斷此提示詞在開發生命週期中的位置：

研究 → 規劃 → 實作（TDD）→ 審查 → 驗證 → 提交

對於 MEDIUM+ 任務，一律從 /plan 開始。對於 EPIC 任務，使用 blueprint 技能。

模型建議（包含在輸出中）：

範圍	建議模型	理由
TRIVIAL-LOW	Sonnet 4.6	快速、成本效益高，適合簡單任務
MEDIUM	Sonnet 4.6	標準工作的最佳編碼模型
HIGH	Sonnet 4.6（主要）+ Opus 4.6（規劃）	Opus 負責架構，Sonnet 負責實作
EPIC	Opus 4.6（藍圖）+ Sonnet 4.6（執行）	深度推理，適合多階段規劃

多提示詞拆分（適用於 HIGH/EPIC 範圍）：

對於超出單一工作階段的任務，拆分為順序提示詞：

• 提示詞 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 [feature]. /tdd to implement. /code-review. /verify.
Bug 修復	/tdd — write failing test for [bug]. Fix to green. /verify.
重構	/refactor-clean [scope]. /code-review. /verify.
研究	Use search-first skill for [topic]. /plan based on findings.
測試	/tdd [module]. /e2e for critical flows. /test-coverage.
審查	/code-review. Then use security-reviewer agent.
文件	/update-docs. /update-codemaps.
EPIC	Use blueprint skill for "[objective]". Execute phases with /verify gates.

區段 5：改進理由

改進項目	理由
（加入了什麼）	（為什麼重要）

頁尾

不是你要的？告訴我該調整什麼，或者如果你想要執行而非提示詞優化，請提出一般的任務請求。

---

範例

觸發範例

• "Optimize this prompt for ECC"
• "Rewrite this prompt so Claude Code uses the right commands"
• "幫我優化這個指令"
• "How should I prompt ECC for this task?"

範例 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：EPIC 專案

使用者輸入：

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. Use /resume-session to continue.
Use git worktrees for parallel service extraction when dependencies allow.

Recommended: Opus 4.6 for blueprint planning, Sonnet 4.6 for phase execution.

---

相關元件

元件	何時參考
configure-ecc	使用者尚未設定 ECC
skill-stocktake	稽核已安裝哪些元件（取代硬編碼目錄）
search-first	優化提示詞中的研究階段
blueprint	EPIC 範圍的優化提示詞（以技能方式呼叫，非指令）
strategic-compact	長時間工作階段的上下文管理
cost-aware-llm-pipeline	Token 最佳化建議