Bad prompts have a tell. They work once, in the exact context you wrote them for, and then fall apart the moment anything shifts. Different project, different input, different day, and suddenly you're getting garbage output wondering what changed.
Nothing changed. The prompt was just never built to last.
I've been doing this long enough to know the difference between a prompt that got lucky and a prompt that's actually well-constructed. And the fastest way I've found to close that gap is to use Claude not just to run prompts, but to help me write better ones in the first place.
The Problem With One-Shot Prompting
Most builders write prompts the same way. You need Claude to do something, you type what you want, it mostly works, you move on. That's fine for throwaway tasks. But if you're building a workflow, an agent, a repeatable process inside your business, you need prompts that are stable.
One-shot prompts fail because they rely on implied context that only exists in your head at that moment. You know what you meant. Claude is inferring. When that inference lines up, it works. When it doesn't, you get drift.
The fix is treating prompt writing like code review. You don't just write it and ship it. You stress-test it.
Using Claude to Pressure-Test Your Own Prompts
Here's the core move. After you write a prompt, paste it back into Claude with this framing:
I wrote this prompt to accomplish a specific task. Before I deploy it, I want you to identify every assumption I'm making, every place where the output could drift based on slight input variation, and any edge cases that would cause it to fail silently.
That last part matters. Silent failures are the worst kind. The output looks reasonable, you don't catch it, it poisons downstream steps in your workflow.
Claude is good at this because it can see the gap between what you wrote and what you meant. It doesn't have your internal context, so it reads the prompt literally, which is exactly how it will behave when you're not watching.
The Rewrite Loop
Once you get the critique back, you don't just patch the holes. You do a full rewrite pass with the failure modes in mind. Then you run the critique again on the new version.
Two or three rounds of this and you end up with something genuinely robust. Not perfect, but prompt that has been stress-tested instead of just vibed into existence.
The prompts I use inside Vaylo's internal tooling, the ones running inside operators and workflows that touch real clients, almost all of them went through at least two critique rounds before they shipped.
Variables and Slots: Making Prompts Reusable
Another thing I ask Claude to help with is identifying where a prompt should have explicit variables instead of hardcoded values.
Early on I'd write prompts with specifics baked in. A client name, a product category, a tone word. It worked for that one case. Then I'd copy-paste the prompt for a different use case, forget to update one of the hardcoded values, and introduce a bug that was annoying to track down.
Now I ask Claude to spot every place in the prompt where a value is likely to change across use cases and flag it for extraction. You end up with a prompt template with named slots, something like {{client_name}} or {{output_format}}, that you fill programmatically. Much cleaner when you're running these inside Make.com flows or n8n automations.
Testing Against Adversarial Inputs
This is one most people skip entirely. They test their prompts against clean, expected input. Real data is messy.
Ask Claude to generate a set of adversarial test inputs for your prompt. Things like:
- Inputs that are way longer or shorter than expected
- Inputs with missing fields
- Inputs that are ambiguous or contradictory
- Inputs in a slightly different format than you assumed
Then run your prompt against all of them. See where it breaks. Fix those breaks before they happen in production with actual client data on the line.
This takes maybe twenty minutes and has saved me multiple incidents.
Prompt Versioning Without Overhead
When you're iterating on prompts, version them. Not in a complicated system, just in a simple way you'll actually use.
I keep a running doc for each major operator or workflow. Each version of the core prompts lives there with a short note on what changed and why. When something breaks in production, I can roll back to the last known-good version in two minutes instead of trying to remember what I changed three iterations ago.
Cursor is good for this if you're already using it for development. You can keep prompt files in the repo alongside the code that uses them and track changes the same way you track code changes. It sounds like overkill until the first time it saves you.
The exact three-stage sequence, including the specific critique prompt that actually gets useful feedback instead of polite suggestions, is behind the Inner Circle gate. That's where we put the stuff that took real iteration to figure out.
Keep building
- Claude Code: Codebase Onboarding Map from the prompt library
- Gemini vs Claude Side-by-Side Evaluator from the prompt library
- How I Separated Work and Life Inside One Voice Operating System
- The full Vaylo prompt library, new drops weekly
