Let Claude write your prompt: the meta-prompting loop

For a long time I treated prompting as something I had to be good at on the first try. Type the request, hope it lands, redo it when it does not. The habit that fixed that was almost embarrassingly simple: I started asking Claude to help me write the prompt before I ran it. It turns out the model is very good at spotting what is missing from a request, because it is the thing that has to act on it. This is usually called meta-prompting, and here is the loop.

Why bother

A vague prompt does not fail cleanly. It produces a plausible answer to the wrong question, you notice it is off, you re-explain, it drifts somewhere else, and you have burned three rounds and a pile of context getting to what one good prompt would have gotten you first. Every one of those rounds costs time, tokens, and a little more context rot. Sharpening the prompt up front is the cheapest fix there is.

The loop

Four steps: draft, critique, refine, run.

1. Draft, roughly. Write the request the way it comes to you, half-formed is fine. You are not trying to nail it, you are giving the model something to react to.

2. Ask it to critique, not answer. This is the move. Instead of running the rough prompt, ask the model what a good version would need. Something like:

Do not do this yet. Here is a task I want to give you:

"<your rough request>"

What is ambiguous or missing? What would you need to know to do this well?
List the questions you would want answered before you start.

You will usually get back a short list of exactly the things you left implicit: which files, what "done" looks like, constraints you were carrying in your head.

3. Refine. Answer its questions, or better, ask it to fold your answers into a tightened prompt: "rewrite that as a single clear instruction I can hand you." Now you have a prompt that names the target, the constraints, and the shape of a good result.

4. Run the sharpened version. Often in a fresh session, so the back-and-forth of building the prompt does not clutter the context the real work runs in.

A quick example

Rough: "clean up the auth code."

After one critique pass, the questions that surface are the useful ones: which files count as auth, what does "clean up" mean here (dead code, naming, structure, all of it), are there tests to keep green, is there behavior that must not change. Answer those and the refined prompt becomes something like: "in lib/auth/, remove unused exports and rename the three doThing helpers to say what they do, without changing any behavior; the tests in auth.test.js must still pass." That prompt gets it right the first time.

When to reach for it

• Any task bigger than a one-liner. The larger the task, the more a fuzzy prompt costs you in redos.
• When you have tried twice and it keeps missing. That is a sign the prompt, not the model, is underspecified. Stop re-explaining and ask it what it needs.
• Right before a plan-mode run. A sharp prompt makes for a sharp plan. The two techniques stack: meta-prompt to get the request right, then plan mode to get the approach right before any code is written.

The habit underneath it

Meta-prompting is really just the discipline of front-loading clarity instead of discovering it through failed attempts. The same instinct shows up in writing a good CLAUDE.md, where you say the durable facts once so you never have to re-explain them, and it is one of the habits that keep Claude Code fast and cheap rather than thrashy.