Analyze a draft prompt, critique it, match it to ECC ecosystem components,
and output a complete optimized prompt the user can paste and run.
何时使用
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-ecc instead)
User wants a skill inventory (use skill-stocktake instead)
User says "just do it" or "直接做"
工作原理
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.md exists in the working directory — read it for project conventions
build.gradle / pom.xml → Java / Kotlin (then check for quarkus in build file → Quarkus, or spring-boot → Spring Boot)
Package.swift → Swift
Gemfile → Ruby
composer.json → PHP
*.csproj / *.sln → .NET
Makefile / 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.
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-first skill, then /plan)
Prompt 2-N: Implement one phase per prompt (each ends with /verify)
Final Prompt: Integration test + /code-review across all phases
Use /save-session and /resume-session to 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)
/command invocations 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)
Footer
Not what you need? Tell me what to adjust, or make a normal task request
if you want execution instead of prompt optimization.
示例
Trigger Examples
"Optimize this prompt for ECC"
"Rewrite this prompt so Claude Code uses the right commands"
"帮我优化这个指令"
"How should I prompt ECC for this task?"
Example 1: Vague Chinese Prompt (Project Detected)
User input:
帮我写一个用户登录页面
Phase 0 detects:package.json with Next.js 15, TypeScript, Tailwind CSS
Add a REST API endpoint for user profile updates with validation
Phase 0 detects:go.mod with Go 1.22, Chi router
Optimized Prompt (Full):
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)
Example 3: EPIC Project
User input:
Migrate our monolith to microservices
Optimized Prompt (Full):
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.
相关内容 Components
Component
When to Reference
configure-ecc
User hasn't set up ECC yet
skill-stocktake
Audit which components are installed (use instead of hardcoded catalog)
search-first
Research phase in optimized prompts
blueprint
EPIC-scope optimized prompts (invoke as skill, not command)
