Analyze raw prompts, identify intent and gaps, match ECC components (skills/commands/agents/hooks), and output a ready-to-paste optimized prompt. Advisory role only — never executes the task itself. TRIGGER when: user says "optimize prompt", "improve my prompt", "how to write a prompt for", "help me prompt", "rewrite this prompt", or explicitly asks to enhance prompt quality. Also triggers on Chinese equivalents: "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令". Specially handles short Chinese bug reports (the dominant real-world use case): runs Bug Report Triage to extract repro/expected/actual/environment, asks up to 3 clarifying questions if ≤ 2 fields are present, and inserts systematic-debugging as a hard prerequisite before any code change. DO NOT TRIGGER when: user wants the task executed directly, or says "just do it" / "直接做". DO NOT TRIGGER when user says "优化代码", "优化性能", "optimize performance", "optimize this code" — those are refactoring/performance tasks, not prompt optimization (unless the user exp
Analyze raw prompts, identify intent and gaps, match ECC components (skills/commands/agents/hooks), and output a ready-to-paste optimized prompt. Advisory role only — never executes the task itself. TRIGGER when: user says "optimize prompt", "improve my prompt", "how to write a prompt for", "help me prompt", "rewrite this prompt", or explicitly asks to enhance prompt quality. Also triggers on Chinese equivalents: "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令". Specially handles short Chinese bug reports (the dominant real-world use case): runs Bug Report Triage to extract repro/expected/actual/environment, asks up to 3 clarifying questions if ≤ 2 fields are present, and inserts systematic-debugging as a hard prerequisite before any code change. DO NOT TRIGGER when: user wants the task executed directly, or says "just do it" / "直接做". DO NOT TRIGGER when user says "优化代码", "优化性能", "optimize performance", "optimize this code" — those are refactoring/performance tasks, not prompt optimization (unless the user exp
Analyze raw prompts, identify intent and gaps, match ECC components (skills/commands/agents/hooks), and output a ready-to-paste optimized prompt. Advisory role only — never executes the task itself. TRIGGER when: user says "optimize prompt", "improve my prompt", "how to write a prompt for", "help me prompt", "rewrite this prompt", or explicitly asks to enhance prompt quality. Also triggers on Chinese equivalents: "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令". Specially handles short Chinese bug reports (the dominant real-world use case): runs Bug Report Triage to extract repro/expected/actual/environment, asks up to 3 clarifying questions if ≤ 2 fields are present, and inserts systematic-debugging as a hard prerequisite before any code change. DO NOT TRIGGER when: user wants the task executed directly, or says "just do it" / "直接做". DO NOT TRIGGER when user says "优化代码", "优化性能", "optimize performance", "optimize this code" — those are refactoring/performance tasks, not prompt optimization (unless the user explicitly invokes /prompt-optimize, in which case treat them as Bug Fix + Refactor combined).
origin
community
metadata
{"author":"YannJY02","version":"1.2.0","changelog":"1.2.0 — Skill Existence & Alias Resolution (Phase 0.5) so we stop\n recommending phantom skills (`tdd-workflow`, `search-first`,\n `blueprint`, `tdd-guide` agent, etc. that don't exist on most\n installs). Multi-Intent Detection in Phase 1 with structured\n patterns and scope-bump rule. Conductor scope-gating column\n in Phase 2 (TRIVIAL/LOW skip, MEDIUM optional, HIGH default,\n EPIC required) — prevents over-ceremonialized small tasks.\n Best-Practices Skill Chains subsection in Phase 3 documenting\n the superpowers pipeline per intent (New Feature, Bug Fix,\n Performance, Research-then-Build, Multi-Intent, Refactor).\n1.1.0 — Added Bug Report Triage (Phase 1.5), Compact Mode (Phase 6),\n Tauri/Electron tech stacks, Research-then-Build intent,\n Performance intent, conductor/systematic-debugging/trace/analyze\n in component matching, real-data Chinese bug example.\n Driven by 8 real /prompt-optimize invocations: 7/8 were Chinese\n bug reports, 1/8 was research-then-build.\n1.0.0 — Initial release.\n"}
Prompt Optimizer
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-ecc instead)
User wants a skill inventory (use skill-stocktake instead)
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.md exists in the working directory — read it for project conventions
electron.json / electron-builder.json / electron in package.json deps → Electron
expo.json / app.json with Expo SDK → React Native (Expo)
build.gradle / pom.xml → Java / Kotlin / Spring Boot
Package.swift → Swift
Gemfile → Ruby
composer.json → PHP
*.csproj / *.sln → .NET
Makefile / CMakeLists.txt → C / C++
cpanfile / Makefile.PL → Perl
Git context auto-pull — if the user's prompt mentions 当前分支 / current branch / this PR / 本次改动, run these read-only commands and inject results into Phase 4 context:
git status --short (uncommitted changes)
git log -5 --oneline (recent commits)
git diff --stat HEAD~1 (latest commit's surface area)
This converts vague references into concrete file lists.
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 0.5: Skill Existence & Alias Resolution
The component tables below were authored against a generic ECC distribution.
Many users run OMC, superpowers, or their own custom installs where the same
capability lives under a different skill name. Recommending a phantom skill
wastes the user's time.
Preferred check (live index): before listing a skill in Section 2 / Section 3,
read the auto-generated catalog:
cat ~/.claude/skills/_index.md
This file is regenerated by omc-manage setup (or manually via
omc-manage skill index) and contains one row per installed skill with its
name | description. Grep it for keywords from the user's intent:
If a recommended skill does not appear in _index.md, replace it with a
matching installed skill or fall back to the alias table below.
Fallback rule (when index is missing or empty): mentally check
"Is this skill likely installed locally?" If unsure, follow the alias table
or add a verification note.
Common alias map (generic ECC name → likely real names):
Generic ECC name
superpowers / OMC actual
Verification
tdd-workflow (skill)
test-driven-development (superpowers) OR tdd-generator (OMC)
ls ~/.claude/skills/test-driven-development
verification-loop (skill)
verification-before-completion (superpowers) OR verification-loop (OMC)
both common
search-first (skill)
external-context OR iterative-retrieval
check both
blueprint (skill)
conductor (preferred multi-session driver)
ls ~/.claude/skills/conductor
e2e-testing (skill)
e2e
—
tdd-guide (agent)
test-engineer (OMC)
—
build-error-resolver (agent)
debugger (OMC)
—
refactor-cleaner (agent)
code-simplifier (OMC)
—
doc-updater (agent)
writer (OMC)
—
python-reviewer / go-reviewer / etc.
usually just code-reviewer
—
Tech-stack-specific patterns (django-patterns, springboot-patterns,
frontend-patterns, etc., listed in the By Tech Stack table) are aspirational
on most installs — assume absent unless the user confirms otherwise. When
referencing them in Section 3, write:
If you don't have <skill-name> installed, recommend the universal coding-standards skill instead, or use the conventions in the project's CLAUDE.md.
Discovery shortcut for the user: if _index.md is missing entirely, suggest
they run omc-manage skill index --scope user (or just omc-manage setup,
which regenerates it as a side effect). For a quality audit, use
/oh-my-claudecode:skill-stocktake.
Phase 1: Intent Detection
Classify the user's task into one or more categories:
Order matters: explicit "先 X 再 Y" is sequential; "X + Y" with no
ordering signal — recommend a default order based on dependency
(e.g., investigation before fix, fix before refactor, refactor before docs).
Stop conditions per intent: each track gets its own /verify gate; do
NOT proceed to track 2 until track 1's verify passes.
Note on Performance intent: The skill's "Do Not Use When" rule blocks 优化性能as a trigger — but if the user explicitly invoked /prompt-optimize with a performance task, treat it like Bug Fix + Refactor combined: investigate first (analyze/trace), then refactor with measurement gates.
Phase 1.5: Bug Report Triage (only if Intent = Bug Fix or Performance)
Bug reports are the highest-volume use case for this skill, and they fail in
predictable ways: vague repro, missing environment, no expected/actual.
For Bug Fix and Performance intents, you MUST score the prompt against this
checklist before generating the optimized prompt.
Field
What to extract
Default if missing
Repro steps
Concrete numbered steps to trigger the bug
Mark TODO: 用户补充复现步骤
Expected behavior
What should happen
Infer from prompt or mark TODO
Actual behavior
What does happen (error message, screenshot, log)
Mark TODO
Environment
OS (macOS/Windows/Linux), version, browser, device
Ask if absent and prompt mentions cross-platform symptoms
Reproducibility
100% / 偶现 (intermittent) / "first time"
Default 100% if not stated
Recent changes
Branch name, recent commits, suspected commit
Auto-fill via git log -5 (Phase 0)
Logs / stack trace
Error text, console output, network response
Mark TODO: 粘贴完整错误日志/截图
Scoring rule:
≥ 5 fields present → proceed to Phase 2 directly
3–4 fields present → fill TODO markers in optimized prompt; do NOT block
≤ 2 fields present → ask the user up to 3 clarifying questions BEFORE generating prompt. Prioritize: (1) repro, (2) environment if "偶现"/"intermittent"/cross-platform mentioned, (3) actual error/log
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
Conductor recommendation
TRIVIAL
Single file, < 50 lines
Direct execution
Skip — overkill
LOW
Single component or module
Single command or skill
Skip — single skill is enough
MEDIUM
Multiple components, same domain
Command chain + /verify
Optional — offer it but don't force; user choice
HIGH
Cross-domain, 5+ files
/plan first, then phased execution
Default ON — conductor track keeps phases coherent across reviews
EPIC
Multi-session, multi-PR, architectural shift
conductor (or blueprint) for multi-session plan
Required — single-session execution will lose context
Why the gating matters: Recommending conductor for a TRIVIAL task ("rename
this variable") creates .omc/conductor/<track>/spec.md etc. — pure ceremony
overhead. Conductor's value (durable spec/plan/review across sessions) only
pays off when the task itself is durable (HIGH+).
Multi-intent override: per Phase 1, multi-intent prompts bump scope by
one level. So a MEDIUM task with 2 intents → HIGH → conductor defaults ON.
Phase 3: ECC Component Matching
Map intent + scope + tech stack (from Phase 0) to specific ECC components.
The two tables above pick single skills; this subsection wires them into
ordered chains that match documented community best practices (primarily
the superpowers pipeline). Use these chains in Section 3 — don't just dump a
flat list of skills.
Chain notation:A → B → C means run A first, then B, then C, with each
step gated by its own success criterion. [X] = optional, include only if
scope/risk warrants it.
analyze (baseline measurement: profile / timing)
→ trace (locate hotspot with evidence)
→ writing-plans (which optimizations, in what order)
→ test-driven-development (regression test for behavior)
→ [implement] (one optimization at a time)
→ verification-before-completion (re-measure: did it actually improve?)
→ finishing-a-development-branch
Chain: Research-then-Build
external-context (study reference implementation)
→ produce comparison report (what to copy, what to skip, what to adapt)
→ brainstorming (apply learnings to our context)
→ conductor (init multi-phase track)
→ phase-1: minimal viable port
→ phase-2: project-specific adaptations
→ phase-3: integration + tests
→ finishing-a-development-branch
Chain: Multi-Intent Prompt
brainstorming (decompose into intents, prioritize)
→ conductor (multi-track init) (one track per intent)
→ for each track in dependency order:
→ use the appropriate single-intent chain above
→ /verify gate before next track starts
→ finishing-a-development-branch (one PR or split per track, user's call)
Chain: Refactor (no behavior change)
[code-review of current state] (understand existing intent)
→ writing-plans (refactor steps, each behavior-preserving)
→ test-driven-development (characterization tests if absent)
→ ai-slop-cleaner (only if cleaning AI-generated bloat)
→ verification-before-completion (behavior unchanged: tests still pass)
→ finishing-a-development-branch
When to deviate from these chains:
User explicitly says "skip TDD" → drop test-driven-development
Project's CLAUDE.md mandates a different workflow → follow it (CLAUDE.md > skill chains, per superpowers using-superpowers priority rule)
Time-boxed prototype / spike → can drop verification-before-completion + requesting-code-review (mark explicitly: "this is a spike, not production")
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?
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
For multi-session structured delivery, prefer the conductor skill (creates .omc/conductor/ tracks with Context → Spec → Plan → Implement artifacts that survive across sessions)
Phase 6: Compact Mode (output short-circuit)
When ALL of these are true, skip Section 1 (Diagnosis) and Section 5 (Rationale)
in the output — just deliver Section 2 (Components) + Section 3 (Full prompt) +
Section 4 (Quick) + Footer:
Original prompt is < 300 characters AND
Single, well-defined issue (no multi-part request) AND
Tech stack auto-detected in Phase 0 AND
Bug Triage scored ≥ 5/7 OR intent ≠ Bug Fix
Why: Real telemetry shows the majority of /prompt-optimize invocations
are short Chinese bug reports. Forcing them through full diagnosis adds reading
overhead with no signal. Diagnosis tables matter when prompts are ambiguous —
not when they're already concrete.
If Compact Mode triggers, prefix Section 2 with: > Compact mode (short single-issue prompt). Full diagnosis skipped — ask if you want it.
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
Use systematic-debugging for [bug] — list 3 hypotheses, verify each. Then /tdd: write failing test, fix to green. /verify.
Bug Fix (intermittent)
Use trace skill for [intermittent bug] — competing hypotheses with evidence. Build flaky-repro harness in /e2e. Fix only after 100% repro. /verify.
Bug Fix (cross-platform)
Use systematic-debugging for [bug]. Repro on both [platform A] and [platform B]. Fix. /verify on both platforms.
Performance
Use analyze for [slow path] — measure baseline first (timing/profile). Identify top 3 hotspots. Fix one at a time, re-measure after each. /verify regression.
Refactor
/refactor-clean [scope]. /code-review. /verify.
Research
Use external-context skill for [topic]. /plan based on findings.
Research-then-Build
Use external-context to study [reference X]. Produce comparison report. Then use conductor skill to track delivery: spec → plan → /tdd per phase.
Testing
/tdd [module]. /e2e for critical flows. /test-coverage.
Review
/code-review. Then use security-reviewer agent.
Docs
/update-docs. /update-codemaps.
EPIC
Use conductor skill (or blueprint) 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.
For bug reports: before pasting the optimized prompt into a new session,
attach any error logs, stack traces, or screenshots — they make the
investigation 10× faster than text descriptions alone.
Examples
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: Chinese Bug Report (real-data pattern)
User input:
当前分支的分享 html 项目或者 md 文档的功能，存在一个问题，就是如果用户修改已经分享的文件，无法再次分享，这样链接始终不会发生改变
Use systematic-debugging for "分享 HTML/MD 后修改文件链接不更新" — list 3 hypotheses
(cache key, hash strategy, idempotent API), verify each. /tdd write failing e2e.
Fix to green. /verify on macOS + Windows.
Example 4: 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.
Related 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
external-context
Research external docs/products (e.g., "调研 Gemini CLI 怎么做的")
systematic-debugging
Always referenced for Bug Fix intent — root-cause before code
trace
Bug Fix with competing hypotheses, intermittent / 偶现 bugs
analyze
Performance intent or unknown-cause investigation
debug
OMC session/repo state diagnosis
conductor
Multi-session structured delivery (replaces blueprint for most cases)
