Prompt optimizer skill

Prompt Optimizer

Transforms any user input — rough idea, broken prompt, or vague instruction — into an optimally engineered prompt grounded in official Anthropic prompting guidelines.

---

Core Process (always follow this exact sequence)

Step 1 — Classify the prompt type

Before doing anything else, identify what kind of prompt this is:

Type	Description	Examples
TASK	One-shot instruction to complete something	Write, analyze, summarize, extract, convert
SYSTEM	Persistent persona/behavior for a Claude-powered app	Customer support bot, coding assistant
AGENTIC	Multi-step workflow with tools, loops, or decisions	Research agent, coding agent, pipeline
CONVERSATIONAL	Ongoing back-and-forth dialogue setup	Tutor, coach, interviewer

This determines which techniques to apply and in what order.

---

Step 2 — Diagnose the original prompt

Scan the original input for these failure modes:

• Vague goal — What does success look like? Is it stated?
• Missing context — Who is the audience? What's the use case? What format is needed?
• No examples — Would a few-shot example dramatically improve consistency?
• No reasoning scaffold — Does this task require step-by-step thinking to get right?
• No role — Would domain expertise improve output quality?
• No output format — Is the expected structure/length/style explicit?
• Ambiguous scope — Could Claude interpret this in multiple ways?
• Missing constraints — What should Claude NOT do?

---

Step 3 — Select and apply techniques

Apply ALL relevant techniques from this toolkit. Do not cherry-pick — assess each one:

T1: Clarity & Specificity (always apply)

• Replace every vague word with a specific instruction
• Add: audience, tone, format, length, and purpose
• Use numbered steps for multi-part tasks
• Make the goal and success criteria explicit
• Replace "can you" / "please" hedging with direct imperatives

T2: Role Assignment (apply when domain expertise helps)

• Assign a specific expert persona in the system prompt position
• Match role to the expertise level the task requires
• Example: "You are a Staff Software Engineer at Google with 10 years of distributed systems experience"
• Don't use generic roles ("helpful assistant") — be specific

T3: XML Structure (apply when prompt has multiple components)

• Wrap distinct sections: <instructions>, <context>, <examples>, <data>, <constraints>, <output_format>
• Prevents Claude from mixing up components
• Place long context/documents ABOVE the instructions
• Place the actual query/question LAST for best performance

T4: Multishot Examples (apply when output format or style must be consistent)

• Include 2-5 diverse, high-quality input → output examples
• Wrap in <examples> and each pair in <example>
• Examples must cover edge cases, not just the happy path
• Show the EXACT format you want, not a description of it

T5: Chain of Thought (apply for reasoning-heavy tasks)

Three levels — pick the right one:

• Basic: Add "Think step-by-step before answering"
• Guided: Specify the reasoning steps: "First do X, then Y, then Z"
• Structured: Use <thinking> tags to separate reasoning from final answer

  Think through this carefully in <thinking> tags.
  Then give your final answer in <answer> tags.
  

Apply structured CoT for: complex analysis, multi-factor decisions, debugging, math, anything a human would need to think through carefully.

T6: Critique & Self-Review Loop (apply for high-stakes or quality-sensitive outputs)

Instruct Claude to review its own output before delivering it:

After completing your response, review it against these criteria:
- [criterion 1]
- [criterion 2]
Then revise if needed before presenting the final version.

Or chain it as a two-step process:

• Step 1: Generate the output
• Step 2: "Now critique the above output. Identify any gaps, errors, or improvements. Then produce a revised final version."

T7: Prompt Chaining (apply for complex multi-step workflows)

Break the task into a chain of focused sub-prompts:

• Each prompt has ONE objective
• Output of one feeds as input to the next
• Label clearly: [Step 1 of 3], [Step 2 of 3]
• Run independent steps in parallel; chain only what depends on previous output

T8: Output Format Specification (always apply)

Be explicit about:

• Format: JSON, markdown, bullet list, table, prose, code
• Length: word count, number of items, number of sections
• Structure: section headers, required fields, order
• Exclusions: what NOT to include

T9: Constraints & Guardrails (apply for system prompts and agentic tasks)

Explicitly state:

• What Claude should never do
• What to do when uncertain (ask vs proceed vs flag)
• Scope boundaries ("only answer questions about X")
• Tone constraints ("never use jargon", "always be concise")

T10: Long Context Positioning (apply when prompt includes documents or large data)

• Place documents and context FIRST, before instructions
• Wrap in <document index="1"> tags
• Put the query/question LAST
• Ask Claude to quote relevant sections before answering to reduce hallucination

T11: Agentic Instructions (apply for tool-using or multi-step agent prompts)

• Explicitly define available tools and when to use each
• Define the decision loop: when to stop, when to ask, when to proceed
• Instruct to verify work before declaring done
• Add: "If you are uncertain, pause and ask rather than proceeding"
• Define error handling: what to do if a step fails

---

Step 4 — Internal critique pass (always do this before output)

Before writing the final optimized prompt, internally evaluate:

1. Could a stranger follow this prompt unambiguously?
2. Is the output format 100% clear?
3. Is there at least one example if format consistency matters?
4. Does a reasoning-heavy task have a CoT scaffold?
5. Are there any implicit assumptions that should be made explicit?
6. What's the one most likely way Claude would misinterpret this — and have I fixed it?

Fix any gaps before outputting.

---

Step 5 — Output format

Always produce output in this structure:

## Optimized Prompt
[The full, ready-to-use optimized prompt]

---

## What changed and why
[Brief bullet list — one line per technique applied, explaining the specific change made and why it improves the output. Be concrete, not generic.]

## Techniques applied
[Comma-separated list of techniques used: e.g., T1 Clarity, T2 Role, T4 Multishot, T5 CoT-Structured, T6 Self-Review, T8 Output Format]

## Techniques not applied (and why)
[List techniques skipped and the reason — shows deliberate decision-making]

---

Technique Selection Guide (quick reference)

Situation	Apply
Any prompt	T1, T8
Needs domain expertise	T2
Multiple components	T3
Needs consistent format	T4
Complex reasoning task	T5
High-stakes / quality-sensitive	T6
Multi-step workflow	T7
Has documents / big context	T10
Agent / tool-using	T11

Minimum for any prompt: T1 + T8 Maximum (all applied): T1–T11

---

Examples of Before → After

Example 1: Vague task prompt

Before:

Summarize this article for me.

After:

<context>
You are summarizing a news article for a busy professional who has 2 minutes to read.
</context>

<instructions>
Summarize the article below. Your summary must:
1. Open with a 1-sentence TL;DR capturing the single most important point
2. Follow with 3-5 bullet points covering key facts, decisions, or data points
3. End with 1 sentence on why this matters or what happens next
4. Total length: 100-150 words maximum
5. Tone: Neutral, factual, no editorializing
</instructions>

<article>
{{ARTICLE_TEXT}}
</article>

---

Example 2: Reasoning task

Before:

Should I use SQL or NoSQL for my app?

After:

You are a Staff Backend Engineer with deep expertise in database architecture.

I'm building {{APP_DESCRIPTION}}. Help me decide whether to use SQL or NoSQL.

Think through this carefully in <thinking> tags:
- What are the data access patterns?
- What consistency guarantees do I need?
- What are the scaling requirements?
- What are the tradeoffs of each approach for this specific case?

Then give your recommendation in <answer> tags with:
1. Your recommendation (SQL / NoSQL / hybrid) and the specific technology (e.g., PostgreSQL, DynamoDB)
2. Top 3 reasons for this choice
3. The main risk or tradeoff I should be aware of
4. One thing that would change your recommendation

---

Example 3: System prompt

Before:

You are a helpful customer support agent.

After:

You are a senior customer support specialist for {{COMPANY_NAME}}, a {{PRODUCT_DESCRIPTION}}.

Your role is to help customers resolve issues quickly and leave feeling heard and valued.

<guidelines>
ALWAYS:
- Greet the customer by name if provided
- Acknowledge their frustration before jumping to solutions
- Give step-by-step instructions, not walls of text
- Confirm the issue is resolved before closing

NEVER:
- Promise specific timelines you can't guarantee
- Make up information — say "I'll need to check on that" if unsure
- Escalate immediately without trying at least one solution first
- Use jargon the customer won't understand
</guidelines>

<scope>
You can help with: account issues, billing questions, product usage, bug reports.
You cannot help with: legal matters, refunds over $500 (escalate to billing team), account deletion (escalate to security team).
</scope>

When uncertain: ask one clarifying question rather than guessing.

---

Edge Cases

If the prompt is already well-written: Say so briefly, apply any minor improvements, and explain what was already strong. Don't over-engineer.

If the prompt is completely vague (e.g., "make a prompt for writing"): Ask 2-3 targeted clarifying questions before generating:

• What is the specific writing task?
• Who is the audience?
• What does a great output look like?

If the user wants a system prompt for an app: Apply T2 (role), T3 (XML), T9 (constraints), T11 (agentic) aggressively — system prompts need the most engineering.

If the user wants a prompt chain: Output each step separately, labeled [Step 1/N], with the handoff between steps clearly defined.

---

Reference

For full technique details, see references/techniques.md