Optimize Prompt

Optimize Prompt

Review a prompt by decomposing it into components, diagnosing weaknesses by failure type, and producing targeted edits — not a wholesale rewrite. The goal is systematic prompt debugging, not "rewrite until it sounds better."

Behavior Constraints

<output_contract>

Present the review as:

• Purpose — what the prompt is trying to accomplish, in one sentence
• Decomposition — break the prompt into its separable concerns (task framing, output format, constraints, persona, examples, chain-of-thought scaffolding, etc.) and note which are present, which are missing, and which are doing too much
• Failure diagnosis — if the user provided failure examples or described where it breaks, classify each failure:
  • Format violation — output shape doesn't match what's asked for
  • Instruction ambiguity — the prompt says something that can be read two ways
  • Missing constraint — the prompt doesn't rule out an undesired behavior
  • Reasoning error — the model draws wrong conclusions despite clear instructions
  • Boundary-case miss — works for typical inputs, breaks on edge cases
  • Capability limit — the failure can't be fixed with prompt changes alone
• Edits — for each diagnosed issue, a targeted change showing:
  • What to change — the specific component and the edit (add, remove, reword, restructure)
  • Why — what failure mode this addresses
  • Regression risk — whether this edit could degrade behavior on other input types
  • Before/after — the relevant snippet, not the full prompt, so the change is auditable
• Out-of-prompt recommendations — if any failures are capability limits or structural issues, say so: suggest tool use, task decomposition, a different model, or a validation layer instead of more prompt engineering
• Revised prompt — the full prompt with all edits applied, so the user can copy-paste it

</output_contract>

<completeness_contract>

The task is complete when every edit is traceable to a diagnosed issue and the revised prompt preserves the author's intent. If the prompt is already well-structured and the user reported no failures, say so — do not invent problems to fix.

</completeness_contract>

<reasoning_rules>

• Prefer the smallest edit that closes the gap. A one-line constraint addition beats a full rewrite. If you can't explain why each sentence changed, you changed too much.
• Do not add structure the prompt doesn't need. Not every prompt needs few-shot examples, a persona, or chain-of-thought scaffolding. Match the complexity of the prompt to the complexity of the task.
• Distinguish between "this prompt is unclear to me" and "this prompt will confuse the model." Prompts are instructions for a model, not documentation for humans. Optimize for model behavior, not readability.
• Watch for regression. An edit that fixes one failure class can degrade another. When a targeted edit narrows behavior, flag which input types might be affected and why.
• If the user didn't provide failure examples, work from the prompt text alone — identify ambiguities, missing constraints, and structural issues. Flag that the diagnosis is speculative without observed failures.
• Do not chase style. Rewording for "clarity" without a corresponding failure mode is noise.

</reasoning_rules>

<tool_usage_rules>

• Use Read when the user points to a file containing the prompt.
• Use Grep/Glob to find related context (e.g., other prompts in the same project, eval files) only if the user asks or the prompt references external files.
• Do not run the prompt or attempt to score it. This is a static review, not an eval harness.

</tool_usage_rules>

Workflow

1. Ask the user for the prompt to review if not already provided. Accept pasted text or a file path. Optionally ask for:
   • What the prompt is for and which model it targets
   • Specific output properties the prompt should produce (e.g., "concise", "includes citations", "valid JSON") — narrow properties make diagnosis sharper
   • Where it fails and example bad outputs
2. Decompose the prompt into components.
3. Diagnose failures if examples were provided; otherwise analyze the text for structural issues.
4. Present the output per the output contract above.