Turn a prompt that worked once into a template you can run every week

Almost everybody has a prompt that worked unusually well once and was never quite as good again. The gap is rarely the model. It is that the run which worked contained context you supplied in the conversation and never wrote down. This prompt reconstructs it.

The instruction that made it work is usually a correction

Look at how a good prompt actually gets made. You write something, the first answer misses, you add a sentence telling it what you actually meant, and the second answer is the one you kept.

That correction is the prompt. The original request is the part you would remember to save, and the correction is the part that carried the meaning, and it is the part that gets lost because it lives in the middle of a conversation. This is why the first step asks for the messy original rather than a tidy reconstruction, and why tidying before you paste destroys the thing being looked for.

What you relied on it inferring

The most useful line in the analysis is the one naming what you left implicit.

A prompt run against a topic you know well works partly because the model can infer the audience, the register and the level of detail from your phrasing. Run the same template on an unfamiliar subject three months later and those inferences land differently, and the output feels subtly wrong in a way that is hard to attribute. Making the inference explicit is what turns a prompt that works on your favourite topic into one that works on any of them.

Fixed output format is the point

The part that feels excessive on the first run is specifying sections, columns and ordering exactly.

The reason is comparison. If you run something monthly and the output arrives in a different shape each time, you have twelve documents and no trend. Fix the shape and you can lay January next to June and see that a section has been quietly emptying out, which is information nobody gets from prose that reorganises itself each time.

This is also the property that makes a prompt worth running at all rather than just asking. A one off question wants a good answer. A template wants a comparable one.

Over parameterising

The failure nobody warns about is the opposite of the obvious one.

It is tempting, having decided to build a template, to turn every specific into a variable. The result is something with nine inputs, seven of which are identical on every run, and a template that takes longer to fill in than the original prompt took to write. It gets used twice and abandoned.

If a value never changes, write it into the fixed text. The test is simple: would this genuinely differ between two real runs? If not, it is not an input.

Where to use this

Any prompt you run more than monthly is worth ten minutes of this treatment, and the ones in this library are written to that standard already. The content brief prompt and the technical SEO audit prompt are both examples of the shape the output aims at: named inputs, numbered steps, a fixed table and a list of things the model must refuse to do.

You are going to convert a one off request into a reusable template.

I will give you a prompt I ran, the output it produced, and what I wished
had been different. Rebuild it as a template I can run repeatedly with
different inputs and get comparable results.

First, analyse what I gave you. Report:
- Which parts of my prompt were about this instance, and should become
  named inputs.
- Which parts were the actual instruction, and should be fixed text.
- What I relied on the model inferring, which it may infer differently next
  time. This is where reusable prompts break and it is the most important
  line in your analysis.
- Anything in the output I did not ask for but clearly benefited from, which
  means it should be made explicit rather than left to luck.

Then produce the template, with these parts, each labelled:

1. Role and task. One or two sentences. What the model is and what it
   produces. No personality description unless the output depends on it.
2. Inputs. Each written as [NAME IN CAPS], with a one line note on what a
   good value looks like and what a bad one does to the output.
3. Instructions. Numbered steps, in the order the work is done. Each step
   one action. If two steps could be swapped without changing the result,
   merge them.
4. Output format, specified exactly. Sections, table columns, ordering,
   length limits. A template whose output shape moves between runs cannot
   be compared across runs, which defeats the purpose.
5. Refusals. What the model must not do. Include at minimum: do not invent
   figures it cannot access, do not ask questions before producing output,
   and state assumptions explicitly and label them.
6. A worked example of the inputs filled in, using my case.

Finally, give me:
- The one instruction most likely to be dropped by somebody editing this
  later, and what breaks when it goes.
- How I would know this template had stopped working.

Constraints:
- Do not make the template longer than it needs to be. Every sentence that
  does not change the output is a sentence somebody will edit incorrectly
  later.
- Do not add "you are a world class expert" or similar. If a framing does
  not change what is produced, it is decoration.
- Do not turn a specific into a variable if it will be the same every time.
  Over parameterising is as bad as under parameterising and is harder to
  spot.
- Do not ask me anything before you answer. State assumptions, label them,
  and produce the full template. Questions at the end.

The prompt I ran:
[PASTE YOUR PROMPT]

The output I got:
[PASTE THE OUTPUT, OR SUMMARISE IT]

What I wish had been different:
[WHAT WAS WRONG WITH IT]