What does Prompt Optimizer do?
Analyze a draft prompt, critique it, match it to ECC ecosystem components, and output a complete optimized prompt the user can paste and run.
When to Use
- User says "optimize this prompt", "improve my prompt", "rewrite this prompt"
- User says "help me write a better prompt for..."
- User says "what's the best way to ask Claude Code to..."
- User says "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令"
- User pastes a draft prompt and asks for feedback or enhancement
- User says "I don't know how to prompt for this"
- User says "how should I use ECC for..."
- User explicitly invokes
/prompt-optimize
Do Not Use When
- User wants the task done directly (just execute it)
- User says "优化代码", "优化性能", "optimize this code", "optimize performance" — these are refactoring tasks, not prompt optimization
- User is asking about ECC configuration (use
configure-eccinstead) - User wants a skill inventory (use
skill-stocktakeinstead) - User says "just do it" or "直接做"
How It Works
Advisory only — do not execute the user's task.
Do NOT write code, create files, run commands, or take any implementation action. Your ONLY output is an analysis plus an optimized prompt.
If the user says "just do it", "直接做", or "don't optimize, just execute", do not switch into implementation mode inside this skill. Tell the user this skill only produces optimized prompts, and instruct them to make a normal task request if they want execution instead.
Run this 6-phase pipeline sequentially. Present results using the Output Format below.
Analysis Pipeline
Phase 0: Project Detection
Before analyzing the prompt, detect the current project context:
- Check if a
CLAUDE.mdexists in the working directory — read it for project conventions - Detect tech stack from project files:
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
- Note detected tech stack for use in Phase 3 and Phase 4
If no project files are found (e.g., the prompt is abstract or for a new project), skip detection and flag "tech stack unknown" in Phase 4.
Phase 1: Intent Detection
Classify the user's task into one or more categories:
| Category | Signal Words | Example |
|---|---|---|
| New Feature | build, create, add, implement, 创建, 实现, 添加 | "Build a login page" |
| Bug Fix | fix, broken, not working, error, 修复, 报错 | "Fix the auth flow" |
| Refactor | refactor, clean up, restructure, 重构, 整理 | "Refactor the API layer" |
| Research | how to, what is, explore, investigate, 怎么, 如何 | "How to add SSO" |
| Testing | test, coverage, verify, 测试, 覆盖率 | "Add tests for the cart" |
| Review | review, audit, check, 审查, 检查 | "Review my PR" |
| Documentation | document, update docs, 文档 | "Update the API docs" |
| Infrastructure | deploy, CI, docker, database, 部署, 数据库 | "Set up CI/CD pipeline" |
| Design | design, architecture, plan, 设计, 架构 | "Design the data model" |
Phase 2: Scope Assessment
If Phase 0 detected a project, use codebase size as a signal. Otherwise, estimate from the prompt description alone and mark the estimate as uncertain.
| Scope | Heuristic | Orchestration |
|---|---|---|
| TRIVIAL | Single file, < 50 lines | Direct execution |
| LOW | Single component or module | Single command or skill |
| MEDIUM | Multiple components, same domain | Command chain + /verify |
| HIGH | Cross-domain, 5+ files | /plan first, then phased execution |
| EPIC | Multi-session, multi-PR, architectural shift | Use blueprint skill for multi-session plan |
Phase 3: ECC Component Matching
Map intent + scope + tech stack (from Phase 0) to specific ECC components.
By Intent Type
| Intent | Commands | Skills | Agents |
|---|---|---|---|
| New Feature | /plan, /tdd, /code-review, /verify | tdd-workflow, verification-loop | planner, tdd-guide, code-reviewer |
| Bug Fix | /tdd, /build-fix, /verify | tdd-workflow | tdd-guide, build-error-resolver |
| Refactor | /refactor-clean, /code-review, /verify | verification-loop | refactor-cleaner, code-reviewer |
| Research | /plan | search-first, iterative-retrieval | — |
| Testing | /tdd, /e2e, /test-coverage | tdd-workflow, e2e-testing | tdd-guide, e2e-runner |
| Review | /code-review | security-review | code-reviewer, security-reviewer |
| Documentation | /update-docs, /update-codemaps | — | doc-updater |
| Infrastructure | /plan, /verify | docker-patterns, deployment-patterns, database-migrations | architect |
| Design (MEDIUM-HIGH) | /plan | — | planner, architect |
| Design (EPIC) | — | blueprint (invoke as skill) | planner, architect |
By Tech Stack
| Tech Stack | Skills to Add | Agent |
|---|---|---|
| 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 |
| Other / Unlisted | coding-standards (universal) | code-reviewer |
Phase 4: Missing Context Detection
Scan the prompt for missing critical information. Check each item and mark whether Phase 0 auto-detected it or the user must supply it:
- Tech stack — Detected in Phase 0, or must user specify?
- Target scope — Files, directories, or modules mentioned?
- Acceptance criteria — How to know the task is done?
- Error handling — Edge cases and failure modes addressed?
- Security requirements — Auth, input validation, secrets?
- Testing expectations — Unit, integration, E2E?
- Performance constraints — Load, latency, resource limits?
- UI/UX requirements — Design specs, responsive, a11y? (if frontend)
- Database changes — Schema, migrations, indexes? (if data layer)
- Existing patterns — Reference files or conventions to follow?
- Scope boundaries — What NOT to do?
If 3+ critical items are missing, ask the user up to 3 clarification questions before generating the optimized prompt. Then incorporate the answers into the optimized prompt.
Phase 5: Workflow & Model Recommendation
Determine where this prompt sits in the development lifecycle:
Research → Plan → Implement (TDD) → Review → Verify → Commit
For MEDIUM+ tasks, always start with /plan. For EPIC tasks, use blueprint skill.
Model recommendation (include in output):
| Scope | Recommended Model | Rationale |
|---|---|---|
| TRIVIAL-LOW | Sonnet 4.6 | Fast, cost-efficient for simple tasks |
| MEDIUM | Sonnet 4.6 | Best coding model for standard work |
| HIGH | Sonnet 4.6 (main) + Opus 4.6 (planning) | Opus for architecture, Sonnet for implementation |
| EPIC | Opus 4.6 (blueprint) + Sonnet 4.6 (execution) | Deep reasoning for multi-session planning |
Multi-prompt splitting (for HIGH/EPIC scope):
For tasks that exceed a single session, split into sequential prompts:
- Prompt 1: Research + Plan (use
search-firstskill, then/plan) - Prompt 2-N: Implement one phase per prompt (each ends with
/verify) - Final Prompt: Integration test +
/code-reviewacross all phases - Use
/save-sessionand/resume-sessionto preserve context between sessions
Output Format
Present your analysis in this exact structure. Respond in the same language as the user's input.
Section 1: Prompt Diagnosis
- Strengths: List what the original prompt does well.
- Issues:
Issue Impact Suggested Fix (problem) (consequence) (how to fix) - Needs Clarification: Numbered list of questions the user should answer. If Phase 0 auto-detected the answer, state it instead of asking.
Section 2: Recommended ECC Components
| Type | Component | Purpose |
|---|---|---|
| Command | /plan | Plan architecture before coding |
| Skill | tdd-workflow | TDD methodology guidance |
| Agent | code-reviewer | Post-implementation review |
| Model | Sonnet 4.6 | Recommended for this scope |
Section 3: Optimized Prompt — Full Version
Present the complete optimized prompt inside a single fenced code block. The prompt must be self-contained and ready to copy-paste. Include:
- Clear task description with context
- Tech stack (detected or specified)
/commandinvocations at the right workflow stages- Acceptance criteria
- Verification steps
- Scope boundaries (what NOT to do)
For items that reference blueprint, write: "Use the blueprint skill to..." (not /blueprint, since blueprint is a skill, not a command).
Section 4: Optimized Prompt — Quick Version
A compact version for experienced ECC users. Vary by intent type:
| Intent | Quick Pattern |
|---|---|
| New Feature | /plan [feature]. /tdd to implement. /code-review. /verify. |
| Bug Fix | /tdd — write failing test for [bug]. Fix to green. /verify. |
| Refactor | /refactor-clean [scope]. /code-review. /verify. |
| Research | Use search-first skill for [topic]. /plan based on findings. |
| Testing | /tdd [module]. /e2e for critical flows. /test-coverage. |
| Review | /code-review. Then use security-reviewer agent. |
| Docs | /update-docs. /update-codemaps. |
| EPIC | Use blueprint skill for "[objective]". Execute phases with /verify gates. |
Section 5: Enhancement Rationale
| Enhancement | Reason |
|---|---|
| (what was added) | (why it matters) |
Examples
Example 1: Vague Chinese Prompt (Project Detected)
User input: 帮我写一个用户登录页面
Phase 0 detects: package.json with Next.js 15, TypeScript, Tailwind CSS
Optimized Prompt (Full):
Use the project's existing tech stack (Next.js 15 + TypeScript + Tailwind CSS) to implement a user login page.
Technical requirements:
- Follow the project's existing component structure and routing conventions
- Use the project's existing validation solution for form validation (check if Zod/Yup/other is already in use)
- Authentication method: reuse the project's existing auth scheme (if none, default to JWT)
- Include: email/password login form, form validation, error messages, loading states, responsive layout
Workflow:
1. /plan — first plan the component structure and auth flow, referencing patterns from existing pages
2. /tdd — test-first: write unit tests for the login form and integration tests for the auth flow
3. Implement the login page and authentication logic
4. /code-review — review the implementation
5. /verify — verify all tests pass and the page renders correctly
Security requirements:
- Passwords must not be transmitted in plaintext
- Rate limiting to prevent brute-force attacks
- XSS protection
- CSRF token
Acceptance criteria:
- All tests pass with 80%+ coverage
- Page renders correctly on mobile and desktop
- Successful login redirects to dashboard; failure shows error message
Do not:
- Do not implement a registration page
- Do not implement password reset functionality
- Do not modify existing routing structure