Most advice on prompting is a pile of tips with no order. This is different: a concrete, numbered process you can run start to finish on any task today. Follow the steps in sequence and you will go from a fuzzy idea to a reliable prompt without guessing.
The process has seven steps, and each one has a clear output. You do not move to the next step until the current one is done. This sounds rigid, but the structure is exactly what makes the result repeatable instead of luck. Once you have run it a few times it becomes automatic.
We will use a single running example throughout so you can see each step applied: turning a messy set of meeting notes into a clean summary with action items. Open your AI tool and follow along.
Step 1: Define the Outcome Before You Write Anything
Before touching the keyboard, finish this sentence: "This prompt succeeds if the output is ___." Be concrete. For our example: "a summary under 150 words plus a bulleted list of action items, each with an owner."
This step matters because you cannot evaluate output you never defined. Skipping it is why people accept mediocre results; they had no bar. Write your success criteria down. It takes thirty seconds and changes everything that follows.
Step 2: State the Task as a Single Imperative
Open your prompt with one clear command verb. "Summarize the following meeting notes and extract action items." Not "I was wondering if you could maybe help me with these notes." The model responds best to direct instructions, and you respond best to clarity about what you actually want.
Why one task at a time
If you need multiple things done, list them explicitly rather than burying them in prose. But resist cramming unrelated tasks into one prompt. Two focused prompts beat one overloaded prompt that does both jobs badly.
Step 3: Supply the Context the Model Cannot Know
The model has no access to your meeting, your team, or your project. Paste the raw notes and add any background it needs: "These are notes from a product team standup. Owners are Maya, Devin, and Priya."
Wrap pasted material in delimiters so the model does not confuse your data with your instructions. Triple quotes or tags both work:
Summarize the notes between the tags.
<notes>
[paste raw notes here]
</notes>Our complete guide explains why this separation prevents the model from treating your data as commands.
Step 4: Specify the Exact Output Format
Tell the model precisely how the answer should look. For our example: "Return a summary paragraph under 150 words, then a section titled Action Items with one bullet per item in the format: [Owner] - [task] - [due date if mentioned]."
Vague format requests produce inconsistent output. Specific ones produce something you can use without reformatting. When format reliability matters most, show a literal example of the structure rather than describing it. The common mistakes guide covers why describing format fails more often than showing it.
Step 5: Add Constraints and Guardrails
State what to avoid. "Do not add action items that are not in the notes. If no owner is named, write 'unassigned.' Do not editorialize." These guardrails prevent the two most common problems: invented content and unwanted commentary.
- Length constraints keep output focused.
- "If unsure, say so" reduces fabrication.
- Scope constraints ("only cover decisions, not discussion") sharpen the result.
Step 6: Run, Read, and Diagnose
Submit the prompt and read the output against your Step 1 criteria. Do not skim. Find the single biggest gap between what you got and what you wanted, and name it precisely: "The summary is good but action items are missing owners."
Diagnose before you fix. A vague reaction like "this isn't quite right" leads to random edits. A precise diagnosis leads to a targeted change. This is the difference between iterating and flailing.
Step 7: Change One Thing, Then Repeat
Fix only the one gap you diagnosed. If owners are missing, strengthen that part of the format instruction or add an example showing owners attached. Rerun and re-evaluate.
Changing one variable at a time is non-negotiable. If you rewrite half the prompt and the output improves, you learned nothing about what actually helped, and you cannot reproduce it. Loop through diagnose-fix-rerun until the output meets your criteria across several different inputs, not just one. Our examples guide shows finished prompts that went through exactly this loop.
A Quick Walk-Through on Our Example
Here is how the running example actually resolves. After Step 5, the first run produces a clean summary but action items without owners. That is the single diagnosed gap from Step 6. In Step 7, rather than rewriting the whole prompt, we add one line to the format spec, "each action item must start with the owner's name from the list above," and append a one-line example: "Maya - finalize the pricing table - by Friday."
The rerun now attaches owners correctly, but a new small issue appears: the model adds an action item that was only a passing comment in the notes. We diagnose that, add the guardrail "include only items explicitly stated as tasks," and rerun once more. The third output meets every success criterion. Two targeted changes, each isolating one variable, got us there far faster than a frustrated rewrite would have. This is the loop in motion, and it converges precisely because we resisted changing several things at once.
Turning the Result Into a Reusable Template
Once a prompt works reliably, do not throw it away. Replace the specific details with labeled slots and save it: "Summarize the [TYPE] notes between the tags. Owners are [NAMES]." Next time you have meeting notes, you fill three blanks instead of starting over.
A small library of battle-tested templates for your recurring tasks is the real payoff of this process. You do the careful work once and reuse it indefinitely. The checklist is a handy final pass before you save a template as production-ready.
Frequently Asked Questions
How long does this seven-step process take?
The first time, maybe ten minutes. After a few runs it collapses to two or three because the steps become instinctive. For a prompt you will reuse often, that upfront investment pays back many times over compared to re-improvising every time.
Do I really need to write down success criteria every time?
For anything that matters, yes. Writing it down forces you to know what you actually want, which is the most common gap. For trivial one-off questions you can skip it, but for any prompt you will reuse or any output that needs to be correct, define success first.
What if changing one thing at a time is too slow?
It feels slow but it is faster overall, because it tells you exactly which change worked. Batch-changing five things and getting a better result leaves you unable to reproduce or refine it. Disciplined iteration converges; random rewriting wanders.
When should I use an example versus just describing what I want?
Use an example whenever format or style consistency matters. Descriptions work for simple tasks, but for anything where the exact structure matters, showing the model one concrete example is far more reliable than any verbal description.
How do I know when to stop iterating?
Stop when the output meets your Step 1 criteria across several varied inputs, not just the one you tested first. Reliability across different inputs is the real finish line. If it works once but breaks on the next input, you are not done.
Key Takeaways
- Define success criteria before writing anything; you cannot evaluate undefined output.
- Lead with a single imperative task and supply context the model cannot infer.
- Separate data from instructions with delimiters, and specify the exact output format.
- Add guardrails against fabrication and off-topic commentary.
- Diagnose precisely, change one variable per iteration, and save winning prompts as templates.