Here is the failure this fixes, and it is a strange one because nothing looks broken.
You write a prompt. It is not bad. You have context in there, a role, a format, everything the earlier techniques told you to include. The output comes back and it is fine, and you know, in a way you cannot justify, that a better prompt exists for this. You just cannot see it, because the thing missing from your prompt is a thing you do not know about.
That is the shape of the problem. Every technique so far has assumed you know what your prompt should contain and simply forgot to say it. Sometimes you do not know. Ask for a code review prompt in a domain you have never reviewed code in, and you cannot list the failure modes it should catch, because listing them is the expertise you were hoping to borrow.
So stop asking for the work.
Do not ask the model to do the task. Ask it to write the brief, then run the brief.
That is meta-prompting: prompting one level up. You describe the task, your situation and what the prompt has to survive, and the model returns a prompt. Then you use it. It is what professional prompt engineers and AI product teams spend most of their day doing, and it is unreasonably effective for technical, structured and domain-specialised work, where model-generated prompts consistently outperform human-written ones.
Where it earns its keep
- Domains you do not know. The model knows which questions a specialist would ask. You do not, which is exactly why you are here.
- Complex multi-step tasks. It structures the pipeline instead of leaving you to discover the missing step at step four.
- Reusable templates. A prompt your whole team will run a hundred times is worth designing rather than typing.
- The unnameable weakness. When your prompt disappoints you and you cannot point at why, describing the disappointment is easier than fixing it, and describing it is all this technique needs.