The dirty secret of working with AI is that most people treat prompts like search queries. Type something in, hope for the best, tweak it manually if it breaks. Repeat forever.
That's not a workflow. That's guesswork with extra steps.
What I do instead is use Claude to help me build the prompts themselves. Not just once, but iteratively, until I have something I can drop into any session and get a consistent, useful output. Prompt engineering as a real practice, not an afterthought.
Here's how that actually works.
The Problem With Writing Prompts Off the Top of Your Head
When you write a prompt cold, you're missing context that you already have in your head but haven't said out loud. You know what output you want. You know what bad output looks like. You know the edge cases. But the model doesn't, because you didn't write any of that down.
So you get an output that's close but off. You tweak the prompt slightly. You get another output. Still off in a different way. You're chasing your own vague mental image and the model is just trying to keep up.
The fix is simple: stop writing prompts in isolation. Use Claude to help you figure out what the prompt actually needs to say.
Start With the Output, Not the Instruction
When I'm building a new prompt for a recurring task, I don't start by writing the prompt. I start by describing the output I want and asking Claude to help me reverse-engineer what the prompt should look like.
Something like this:
"I want to build a reusable prompt for [task]. The output should look like [description]. Here's an example of output I'd consider good: [example]. What does the prompt need to include to consistently produce this?"
This flips the dynamic. Instead of writing instructions and hoping the output matches, you describe the target and let Claude tell you what instructions would get you there.
It works because Claude understands its own tendencies. It knows what kinds of instructions produce what kinds of outputs. You're essentially asking it to map backward from destination to directions.
Then Test It Immediately in the Same Session
Once Claude drafts a prompt for me, I don't save it and move on. I test it right there. I paste the generated prompt back in as if I'm a fresh user running it for the first time.
If the output is good, great. If it's off, I tell Claude exactly what's wrong and ask it to adjust the prompt, not the output. That distinction matters. You're not asking it to fix this response. You're asking it to fix the instruction so future responses are better by default.
Three or four rounds of this in a single session usually gives me a prompt that's solid enough to save and reuse.
Add Constraints and Failure Modes Explicitly
One of the most useful things Claude helped me figure out: good prompts don't just describe what you want. They describe what you don't want, and what should happen when the input is ambiguous or incomplete.
I started asking Claude this question after every draft:
"What would cause this prompt to produce a bad output? What inputs or situations would break it?"
Claude will usually surface three or four real failure modes you hadn't thought about. Then you add language to the prompt to handle them. Now you have a prompt that's robust, not just functional under ideal conditions.
This alone cut my prompt iteration time in half. Instead of discovering failure modes in production, I find them in the session where I'm building the prompt.
Store Prompts Like Code, Not Notes
Once a prompt is refined and tested, it goes into a dedicated doc. Not a random notes app. An actual prompt library with version numbers, the use case, any known limitations, and the date last updated.
I treat prompts like functions. They have a purpose, they take inputs, they return outputs. When a prompt stops working well because a model update changed behavior, I know exactly where to go fix it and I have a record of what it used to do.
This is especially useful if you're running automations in n8n or Make.com where the prompt is embedded in a workflow node. You want to know what prompt is running, why it was written that way, and when it was last reviewed.
When to Let Claude Rewrite a Prompt From Scratch vs. Patch It
Not every broken prompt needs a patch. Sometimes the structure is wrong from the start and you're better off rebuilding.
My rule: if you've iterated more than three times and you're still getting inconsistent outputs, stop patching. Tell Claude the whole situation, show it the current prompt, show it the bad outputs, and ask it to rewrite the prompt with a different structure entirely.
Sometimes the issue is that the prompt is doing too much. Sometimes it's ambiguous in a way that's hard to patch. A clean rewrite with fresh framing usually solves it faster than another round of tweaks.
The full meta-prompt structure, the follow-up review pass, and the automation-specific guardrail layer are all inside Inner Circle. That's where we get into the actual mechanics, not just the concept.
If you're building with AI tools and you want the exact workflows we run at Vaylo, Inner Circle is where that lives.
Keep building
- Claude Code: Codebase Onboarding Map from the prompt library
- Gemini vs Claude Side-by-Side Evaluator from the prompt library
- How I Split My Business Brain Into Two Worlds and Made Both Smarter
- The full Vaylo prompt library, new drops weekly
