In prompt optimization, what does a meta-prompt that rewrites another prompt contain?
answer
- a prompt about a prompt
- four slots, not free-form prose
- current text plus task spec
- failure evidence is load-bearing
- delimited output, no commentary
basics
~20 sA meta-prompt is a prompt whose subject is another prompt. It carries four things: a specification of the task, the current prompt verbatim, concrete evidence of how that prompt failed, and an instruction to emit a revised prompt in a fixed format.
solid answer
~50 sA meta-prompt asks a model to do prompt engineering rather than the task itself, so everything it needs must be in the text — it cannot see your eval harness. Four slots do the work: **the task specification** (what the prompt is supposed to achieve, and what a correct output looks like); **the current prompt**, quoted verbatim inside delimiters so the model does not confuse it with the surrounding instructions; **failure evidence** — a handful of concrete cases showing input, the output the current prompt produced, and the expected output; and **an edit instruction plus an output contract**, e.g. "rewrite the instruction so these cases come out right without breaking the ones that pass; output only the new instruction between `<prompt>` tags". A typical shape is to feed the five worst-scoring outputs from the last evaluation run. Without the failure evidence the model has nothing to diagnose and will simply pad the prompt with generic caution.
code
markdown · 21 lines# Task
Classify a shipping-incident report as DELAY, DAMAGE, LOST or OTHER.
Output exactly one label, uppercase, nothing else.
# Current instruction
<current>
Read the report and say what kind of incident it is.
</current>
# Failing cases (5 worst-scoring from the last run)
1. input: "Pallet arrived crushed on one corner, contents wet."
got: "It looks like the shipment was damaged in transit."
expected: "DAMAGE"
2. input: "Scanned in Rotterdam on the 3rd, no events since."
got: "DELAY"
expected: "LOST"
# Your job
Rewrite the instruction so these cases come out right without breaking
cases that already pass. Prefer removing ambiguity over adding caveats.
Output ONLY the new instruction between <prompt> and </prompt>.go deeper
Be able to say plainly that a meta-prompt is a prompt whose input is another prompt, and name the four things it must carry: the task, the current prompt, real failures, and the edit instruction.
Explain why the failure evidence is what makes the rewrite targeted rather than decorative, and why the output format has to be constrained so a loop can extract the candidate automatically.
Show judgment about which failures to sample and how many, why passing cases are worth including, and that a rewrite is a candidate to be scored with the production executor, never an accepted improvement.
Own the question of who reviews model-written prompts before they ship: how candidates are versioned, diffed and rolled back, and where the boundary sits between an automated rewrite and a human-owned instruction.
## What a meta-prompt is A meta-prompt is a prompt whose subject matter is another prompt. The model reading it is not performing the task; it is performing prompt engineering *on* the task prompt and returning a new candidate. This is the atom of automatic prompt engineering: whatever search or scoring machinery sits around it, the actual writing of a new prompt happens inside one meta-prompt call. The critical property is that the rewriting model is blind. It cannot see your evaluation harness, your dataset, your score, or the production traffic the prompt failed on. Anything it should reason about has to be serialized into the meta-prompt text. Most weak meta-prompts fail for exactly this reason: they say "improve this prompt" and give the model no basis on which to decide what "improve" means, so it falls back on generic writing advice — more structure, more caveats, more politeness — none of which is grounded in the task's actual failures. ## The four slots **1. Task specification.** State what the prompt is for, what the inputs look like, what a correct output looks like, and any hard constraints (output format, forbidden content, length). Without this the rewriter infers the task from the prompt it is being asked to fix — which means it inherits that prompt's misunderstanding. **2. The current prompt, verbatim and delimited.** Quote it inside an unambiguous fence so the model can tell the material-under-edit apart from the instructions addressed to it. Meta-prompts confuse models when the two run together; the model then "helpfully" answers the task prompt instead of rewriting it. **3. Failure evidence.** Concrete cases, each showing the input, what the current prompt actually produced, and what was expected. This is the load-bearing slot. A rewrite grounded in "on these three refund questions the model answered from memory instead of quoting the policy text" produces a targeted edit; a rewrite grounded in nothing produces prose. **4. Edit instruction and output contract.** Say what kind of edit you want ("fix these failures without regressing the passing cases", "prefer deleting an ambiguous sentence over adding a new one", "keep it under 200 words") and how to return it ("output only the new instruction between `<prompt>` and `</prompt>`, no commentary"). The contract exists so the surrounding loop can extract the candidate mechanically instead of parsing an essay. ## Choosing the evidence Show a small, diverse sample — commonly the worst-scoring handful from the last evaluation round, deduplicated so five near-identical items do not dominate. Showing everything is both expensive and counterproductive: the more specific cases you paste, the more the rewrite tends to encode those exact items rather than the rule behind them. Some practitioners also include one or two *passing* cases, labelled as such, so the rewrite has something to avoid breaking. ## Failure modes of the meta-prompt itself - **"Make it better" with no evidence.** The model appends adjectives. Nothing measurable changes. - **No output contract.** The model returns a rewrite wrapped in explanation, and the loop stores the explanation as the prompt. - **Task spec and current prompt merged.** The model answers the task instead of editing. - **Asking for a rewrite and an explanation in one turn without separating them.** Fine if you parse the delimiters; a bug source if you do not. - **Accepting the rewrite unscored.** A meta-prompt produces a *candidate*, never a verified improvement. It must be run against the same evaluation as the incumbent before it replaces anything. ## The rewriter is not necessarily the executor The model that rewrites and the model that runs the resulting prompt need not be the same. A stronger rewriter can write instructions a weaker executor cannot reliably follow, so scoring must always use the executor that will run in production. Conversely, a rewriter that shares the executor's blind spots may keep proposing edits that read well and change nothing. ## What sits around it One meta-prompt call is a single edit. Turning it into an optimization method requires deciding how candidates are proposed at scale, how they are scored, and how the search over them proceeds — separate concerns with their own machinery. The meta-prompt is where the field's actual leverage lives, though: the difference between a loop that improves a prompt and one that inflates it is usually visible in the four slots above.
- How many failing cases would you paste into one meta-prompt, and why not all of them?A handful — typically five to ten, sampled across distinct failure clusters and deduplicated. Beyond that you pay context cost for little diagnostic gain, and the rewrite starts encoding the specific items shown rather than the rule behind them. Diversity matters more than volume: five different ways the prompt breaks is far more useful than fifty instances of the same break.
- Why insist that the rewritten prompt come back inside delimiters with no commentary?So the loop can extract the candidate mechanically. Without a contract the model returns "Here's an improved version, I've clarified the tone…" and a naive extractor stores that preamble as part of the prompt. Delimiters also let you detect a malformed response and retry rather than silently corrupting the candidate pool.
- Should the model doing the rewriting be the same one that will run the prompt?Not necessarily, but the scoring must use the executor. A stronger rewriter often writes instructions a weaker executor cannot follow, so a candidate that looks excellent is only real if it scores well when the production model runs it. Using the same model for both is simpler and avoids that mismatch, at the cost of inheriting its blind spots.
saying these in an interview costs you the question
- Thinks a meta-prompt is just asking the model to make the prompt better
- Omits failing examples and expects the model to guess what broke
- Pastes the entire evaluation set into the meta-prompt
- Accepts the rewritten prompt without re-scoring it against the incumbent
- Confuses a meta-prompt with a system prompt for the task itself