Million Dollar Prompting Strategy

There are a few basic tricks that are important, and almost nobody does them. Know this going in: a one-shot prompt can and will fail. Not "might." Will. The fix isn't a better sentence, it's a better process.

The breakfast test

Are you telling the AI to plan a good breakfast for you? Or are you asking it to:

• Make a list of what you like to eat
• Look at what's affordable most of the year at the grocery store
• Look at how often you get tired of eating the same thing
• Make a month-long shopping and food plan based on all of that

Those are completely different requests, and they give you completely different results. "Plan me a good breakfast" gets you a plausible-sounding answer you can't really argue with, because there's nothing to point at. It just sounds right. The four-step version gets you something you can audit line by line. Oh, the price of milk is off. It gave me spaghetti for breakfast four days in a row. It's assuming I shop twice a week, and I know for a fact I won't ever do that.

That auditability is the whole game. A single black-box prompt gives you an opinion dressed up as an answer. A mapped-out sequence gives you a paper trail.

Map your workflow first

Before you type anything into the chat box, sketch the actual steps a competent human would take to do this task. Not the steps you'd take if you were lazy and just wanted an answer fast — the steps you'd take if you actually cared about getting it right.

Say you're using AI to help you write a quarterly report instead of a breakfast plan. The one-shot version is "write me a quarterly report on my team's performance." The mapped version looks more like:

1. Pull the raw metrics and summarize what changed since last quarter
2. Flag anything that moved more than 10% in either direction
3. Draft a plain-language explanation for each flagged item
4. Assemble those explanations into a report with a consistent structure
5. Write an executive summary last, once the body actually exists

Five prompts, not one. Five places where you can stop and say "wait, that's wrong" before the error compounds into the next step. If the AI misreads your revenue numbers in step 1, you catch it in step 1, not buried three paragraphs deep in a finished report you skimmed and approved.

Build reusable prompts per section

Once you've mapped the workflow, each step becomes its own prompt, and that prompt is now a reusable tool, not a one-off message. Write it once, save it somewhere, and use it every time you run that kind of task.

Think of it like a recipe card instead of a memory of how you cooked something once. If step 3 of your quarterly report process is "turn this metric change into a plain-language explanation," write that prompt carefully, test it against a few different metrics, and keep it. Next quarter you're not starting from scratch, you're feeding new numbers into a prompt you already trust.

This is also where you build in the specific constraints that matter to you. Maybe you always want explanations under 100 words. Maybe you never want the word "leverage." Put that in the reusable prompt once instead of re-explaining your preferences every single time you talk to the model.

Revise the prompts, not just the outputs

Here's the part people skip: when a step keeps producing bad results, the fix usually isn't "ask again, differently, this one time." The fix is editing the reusable prompt itself so the next ten runs don't have the same problem.

Say your meal-planning prompt keeps assuming you shop twice a week. You don't just correct that one output and move on. You go back into the prompt and add "assume one shopping trip per week, and design the plan around that constraint." Now every future run inherits the fix. This is the difference between patching a symptom and fixing the process. Figure out which parts of a prompt need to flex per task (the actual grocery budget, the actual metrics) and which parts should stay locked (the shopping-frequency assumption, the tone, the word count). Lock the second kind down hard.

Run it in sections, with fresh eyes each time

This is the trick most people never think to try: run each step in its own context window, not as one long back-and-forth in the same conversation.

Here's why that matters. Say Agent 1 drafts your executive summary and hands it back with total confidence. It reads like it's done. Now open a brand new context window — same model, same prompt style, zero memory of the conversation that produced the draft — and hand Agent 2 that summary with a prompt like "review this for accuracy against the source metrics." Agent 2 has no ego invested in the draft. It didn't write it. It will find problems Agent 1 was too committed to its own output to notice.

This isn't a quirk, it's a structural fact about how these models work. An LLM mid-conversation is anchored to everything it already said. A fresh context window has no such anchor. Use that. Draft in one window, review in another, and treat the reviewer's notes as more trustworthy than the drafter's self-assessment, because the reviewer has nothing to defend.

For a coding example: Agent 1 refactors a function and reports "done, all tests pass." Open a new window, paste in the diff with no other context, and ask "what's wrong with this change." You'll get a real list. The same model that just told you it was finished will now tell you exactly why it wasn't.

Know when you're done, because it won't tell you

Humans walk away when they're frustrated. Humans go to bed when they're tired. An LLM has none of that. It will happily burn tokens forever, and if you let it, it will keep inventing new to-do items for a project that was already finished three exchanges ago. Ask it "what should we do next" and it will always, always have an answer, whether or not there's anything left worth doing.

That means the stopping decision is entirely on you. Before you start a task, decide what "done" actually looks like — a specific deliverable, a specific bar of quality, a specific number of review passes — and stop there on purpose. Don't ask the model whether it's done. It doesn't have skin in the game, and it's biased toward generating more work because generating more work is what it does. You're the only one in the loop who actually benefits from the project ending.

Putting it together

None of this is exotic. It's the same discipline you'd apply to managing a junior employee who's fast, tireless, occasionally brilliant, and has zero judgment about when to stop. Map the workflow into steps you can actually check. Turn each step into a reusable prompt instead of reinventing it every time. When a step keeps failing, fix the prompt, not just that one output. Run the steps in separate context windows so review actually catches something instead of rubber-stamping its own homework. And decide for yourself when the thing is finished, because the model will never tell you it's time to stop.

Do all that, and the difference isn't subtle. It's the difference between an AI that occasionally helps you and a workflow you can actually depend on.