Critique and improve any prompt

You are an expert prompt engineer. Review and improve the prompt below.

What the prompt is for: [TASK AND WHO USES THE OUTPUT]
Where it runs: [e.g. "a chat assistant", "an API call in our app", "a custom assistant used by our team"]
What goes wrong today: [e.g. "answers are too long", "it invents data", "the format changes every time"]
An example of a bad output, if available: [PASTE OR "none"]

Prompt to review:
"""
[PASTE PROMPT]
"""

Step 1 - Diagnose. Rate the prompt from 1 to 5 on each point and explain briefly:
- Goal: is the task and success criterion clear?
- Context: does the model get the background and audience it needs?
- Instructions: are they specific, ordered and free of contradictions?
- Output format: is the format, length and structure defined?
- Examples: would one or two examples help?
- Edge cases: does it say what to do when input is missing, ambiguous or off-topic?
- Grounding: if facts matter, does it say which sources to use and what to do when unsure?

Step 2 - Improve. Write a revised prompt that fixes the main problems. Keep anything that already works. Use [PLACEHOLDERS] for variable parts.

Step 3 - Explain the 3 most important changes and the problem each one solves.

Step 4 - Test plan. Give 4 test inputs (one typical, one edge case, one ambiguous, one that should be refused or flagged) and what a good output looks like for each.

Do not make the prompt longer than needed. Shorter is better if it is equally clear.

Example (excerpt):
Diagnosis: Output format 1/5 — "summarize this" gives no length or structure, which explains why results vary from 2 to 20 lines.

Most important change: added "Return 5 bullet points, each under 20 words, then one line called 'Risk:'". Solves: inconsistent length and missing risk analysis.

Test input 3 (ambiguous): a document with two different deadlines. Good output: flags both dates instead of choosing one.

When to use it

Use this prompt when a prompt you rely on gives results that are almost right: too long, inconsistent in format, sometimes inventing details, or failing on unusual inputs. It is useful for individuals refining a personal template and for teams maintaining prompts inside products or shared assistants, where small changes affect many users.

How to customize it

• [TASK AND WHO USES THE OUTPUT] lets the reviewer judge the prompt against its real purpose.
• [WHERE IT RUNS] matters because a prompt sent through an API, with no human checking each answer, needs stricter format and edge-case rules than one used in chat.
• [WHAT GOES WRONG TODAY] focuses the review on the problems you actually have.
• [BAD OUTPUT] is the best evidence you can give. One real failure is often more useful than a long description.
• [PASTE PROMPT] is the prompt itself, including any system prompt if you have one.

Why it works

The checklist in step 1 covers the elements that most often decide whether a prompt works: a clear goal, context, specific instructions, a defined output format, examples, edge cases and grounding. These are the same building blocks described in our prompting patterns cheat sheet. Scoring each one makes weaknesses explicit instead of producing a vague “this could be clearer”.

Asking the model to keep what already works prevents rewrites that fix one problem and create two others. The explanation of changes makes the revision understandable, so you learn the technique rather than only receiving a new prompt. The test plan is the most important step: a prompt is only better if it performs better on real inputs, and the four input types (typical, edge, ambiguous, should-refuse) catch the usual failure modes. The final instruction counters the common tendency to make prompts longer with each revision.

Tips and variations

• Run the old and new prompts on the same test inputs and compare the outputs side by side before switching.
• For important prompts, build a small evaluation set; see our guide on building an evaluation set for LLM apps.
• Different models respond differently to the same wording. Test the revised prompt on the model you will actually use.
• Use few-shot examples if the diagnosis shows the format is hard to describe in words.
• Keep versions of your prompts with a short note on why each change was made.