prompt-optimizer

name	prompt-optimizer
description	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.4.0","changelog":"1.4.0 — Added stack-aware UI Interaction Optimization routing. Web product\n prompts now receive a small ordered combination drawn from the\n local impeccable/visual-verdict skills and the curated\n emilkowalski motion suite. React Native uses animate-expo, while\n native SwiftUI stays on the local SwiftUI pack. The router never\n recommends the excluded emil-design-eng or write-swift skills.\n1.3.0 — Phase 0.7 Project Context Probe. The skill now reads the actual\n repo (stack manifest, git state, README/AGENTS.md)\n before producing the optimized prompt, so recommendations cite\n real file paths, branch names, and declared versions instead of\n generic templates. Hard rules R1-R6.5 prevent the probe from\n misleading downstream agents:\n • R1 — 3-section Facts / Inferences (UNVERIFIED) / Unknown block\n • R2 — never reference code symbols the probe did not actually Read\n (commit subjects and branch names are not code verification)\n • R3 — branch names do not determine intent; skill selection uses\n user prompt + Facts.stack only\n • R4 — declared manifest version ≠ installed version; lockfile\n must be checked when exact runtime version matters\n • R5 — README/AGENTS.md content gets 1 line + source +\n last-modified date; declared-vs-detected conflicts get\n an explicit ⚠️ flag\n • R6 — mandatory \"Re-verify before mutating\" footer in every block\n • R6.5 — probe failures are explicit (\"PROBE FAILED: <reason>\"),\n never silently empty\n Section 3 (Optimized Prompt — Full) now MUST start with the verbatim\n Context Block and cite ≥ 2 Facts. Self-check gate added before\n publishing output. New Example 5 demonstrates the full probe →\n 3-section block → safe \"starting points to verify\" output pattern\n on a real SwiftUI iOS scenario. Budget: ≤ 6 read-only tool calls.\n Graceful degradation: works in non-git dirs, unknown stacks, and\n repos without self-description docs.\n1.2.1 — Fix phantom `/tdd` references (13 occurrences across Phase 1.5\n template, Phase 3 By-Intent table, Section 4 Quick Patterns,\n and all four examples). No `tdd` skill or command actually\n exists; the canonical name is `test-driven-development`\n (superpowers) — already mapped in the Phase 0.5 alias table\n but not applied to our own templates. This release closes that\n self-inconsistency. Added explicit `/tdd → /test-driven-development`\n row in the alias table to prevent regression.\n1.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 OpenCode 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:

1. Check if a AGENTS.md exists in the working directory — read it for project conventions
2. Detect tech stack from project files:
   • package.json → Node.js / TypeScript / React / Next.js
   • go.mod → Go
   • pyproject.toml / requirements.txt → Python
   • Cargo.toml → Rust
   • src-tauri/ + Cargo.toml + package.json → Tauri (Rust core + Web frontend)
   • electron.json / / in deps →