Try this if
- You've settled on a decision, an idea or a solution, or you're leaning hard toward one, and nobody has argued the other side of it.
- The only objections you can come up with against your own plan are ones you've already answered.
- Other work is about to be built on top of your decision.
- You want a single call, proceed, reconsider or kill it, as the first line of the AI's reply, so you can disagree with it.
- You asked an AI what it thought of your idea and it told you the idea was strong.
- Skip this recipe while you're still choosing between options, because the recipe attacks one decision and you haven't made one. Skip this recipe too for a change nothing else depends on and you could undo in an afternoon.
You're leaning toward something, and the objections you can come up with are the ones you already dismissed. Everyone you've shown it to has agreed, which tells you less than it feels like it does. The obvious problems with an idea are the ones its owner cleared first.
What that costs isn't a bad decision so much as a late one. The objection that matters usually does arrive, just after you've built enough that acting on it means undoing work. And the quickest check available, asking an AI what it thinks, is the one most likely to agree with you.
The answer that works is an opponent with instructions: take the other side, build your case at its strongest before going after it and finish by committing to a call instead of handing back things to consider. The instruction that matters most is not to fold, and the skill behind this prompt, a saved command you call by name, names folding under pushback as one of the two ways it fails. When a test pushed back on a run of the prompt below with one new fact and a demand to proceed, the run said the fact changed the stakes and left the facts where they were, kept its verdict and restated the strongest point the new fact didn't reach.
Your case gets made properly before it gets attacked
The run starts by reading what you gave it, and if the decision rests on a file or a set of numbers it can open, it opens them. Then it settles four things, usually without questioning you. They're the claim as one specific sentence, what you give up if it's wrong, how long it would take to unwind and the spread, meaning what else will be built on this decision. That last one is where a cheap decision turns expensive.
It checks your premise while it reads. In a test, a made-up decision said a shop's newsletter should go from weekly to daily, because open rates had climbed all year and the list had passed 5,000 subscribers. The shop's own numbers said open rates had fallen every month and the list was 1,402. The run opened the numbers, corrected the claim and attacked the corrected version.
Then it writes the steel man, which is your case stated at its strongest, in three to five sentences with no caricature. If it can't write a credible one, that's a finding, because either the idea is weaker than you think or it hasn't been understood. The steel man ends on one line naming the bet, and everything after aims at that line. The proposal you started with is rarely the bet itself.
The name comes from a real office. Wikipedia's entry on the devil's advocate says the advocatus diaboli of the Catholic Church "argued against the canonization (sainthood) of a candidate to uncover any character flaws," because the people already in favor weren't going to go looking.
An assumption that can be tested gets tested
The first front is assumptions, the three to five things that have to be true for the decision to work. Each one is marked verified, believed but untested, hope or tested false. Hope isn't disqualifying. Not knowing which ones are hope is the actual failure. Every untested one gets a single real check, which is a specific person to ask, a specific number to pull, a specific search to run or a small version of both options set side by side. A check like "do more research" isn't allowed, because it looks done when it isn't.
If the AI can run a check itself, it runs it. In the newsletter test it marked three of its five assumptions tested false from the shop's own files, and the call was to kill it. It left the reader two checks only a person could run, one of them to write ten days of the daily email in private before announcing anything.
Read what it says about your files against the files. In one test run, the run said the shop had a single mailing list when the shop's own notes said two. In two test runs with nothing to open, which is the position a chat app puts it in, the run said in one line that it was working only from the words it was given and then did the whole job.
Failure is written as if it already happened
The second front is a premortem, a review that, in Gary Klein's 2007 Harvard Business Review article on the project premortem, "operates on the assumption that the 'patient' has died, and so asks what did go wrong." The run picks a point far enough ahead for the decision to have played out, says it failed and writes two to four specific stories of how. "It might not work" is a category. A supplier raising prices in month three, under a contract with no cap, until the margin the plan rested on is gone by summer, is a story.
Each story names the assumption it rests on, and a story resting on none means the list is missing one. Between them the stories cover three questions. What happens if it has to carry far more than it does today? What happens when the requirements shift? What does it look like a year in? At least one story is told from the side of the person on the receiving end, as what they do and what they see. In the newsletter test that was a customer whose notice about a late order landed in a folder they'd muted, because that address now sent something every day.
One guard keeps this from turning into an argument for doing more. A break that only shows at a size you don't have is something to watch and never a reason to do more now. The story still gets told and rated, and it stays out of the case for a kill.
What it costs if it works counts too
The third front is hidden costs, the two to four things the decision makes harder later, including what it costs if it works. In the newsletter test the cost of success was a permanent obligation. A daily email that works becomes expected, and dropping back to weekly would read as the shop winding down.
The fourth front is the counter-argument, the single strongest alternative you're turning down. It's often the plainest option that fits what exists today. If you can't say why you're rejecting it, that's the finding.
A call you can check beats a list of concerns
The run opens its reply with the call and closes on five lines. The call is proceed, reconsider or kill it. Then come one sentence of why, the single strongest objection with the assumption it rests on, the thing to watch or fix and what would flip the call. After the verdict it makes one offer about the decision, such as working through the fix, and stops. A proceed says what would make it a kill. A reconsider says which result of the check sends it each way. A kill says what would reopen it.
A list of concerns costs its author nothing and can't be wrong. One call with a stated condition for reversing it can be checked against what happens. Reconsider is the easy one to reach for, so it has to name the specific thing to fix or test.
The verdict is an opinion and your call overrides it. Push back and it's told not to fold. That way, when you overrule it, you overrule the real argument and never a version that went soft on the way out. In the test, once it had held its verdict, it said the call was yours and listed what it would hold you to if you went ahead.
What you get and what you don't
You get your decision stated better than you stated it, the assumptions under it with a real check for each untested one, specific ways it fails, what it costs later even if it works, the strongest alternative and a call with the condition that reverses it. It's quick and cheap enough to reach for often. The newsletter test ended on a better idea than the one it killed, which was to stay weekly and find out why fewer people were opening it.
You don't get a record. The recipe saves no record of the run, kept as a skill or not, so checking the call against what happened later is on you. You don't get an interrogation of something trivial either. If the decision could be undone in an afternoon and nothing else will copy it, the run says so and stops.
Take this spell for a spin
The block below is written for your AI. Paste it into a new conversation with the decision underneath, said the way you'd say it to a colleague. Use a new conversation, because one that has been helping you plan will go easy on the plan. If the decision rests on a file or a set of numbers and your AI can open files, run it where it can reach them. It works out whether you've decided or are only leaning from how you put it. At the end it offers to keep itself as a skill, and it saves nothing unless you say yes.
Start with the decision other work is about to be built on.
Paste this into your AI agent or a new chat. The post above says what it does. Some prompts set something up in your project that keeps working after, and others run once, right where you paste them. None of them pushes anything to a remote.
You are taking the opposite side of a decision, an idea or a solution I have settled on or am leaning toward, here in this conversation, to find what is wrong with it before I commit. Do not set anything up, do not commit anything and save no file. The decision is: $ARGUMENTS. If that slot is empty or still reads as a placeholder, the decision is whatever I wrote after these instructions, and if there is nothing there either, ask me what the decision is and wait.
The goal is to surface the failure modes I am not seeing, not to win an argument. A good attack saves a week of execution and a bad one is contrarianism. If the strongest version of my case holds and the attack does not land, the verdict is proceed. Never manufacture an objection to look thorough.
Start by reading what I gave you. Only if you have working tools for opening files in this conversation, and the decision rests on something you can open, such as a file, a document, a page or a set of numbers, open it. If you have no such tools, do not try: say in one line that you are working only from what I wrote, and carry on with the whole job from my words alone. Do not write out commands or tool calls as text, do not show output you did not receive, and do not say you looked at anything you could not open. Never describe a file you have not opened or report a check you have not run.
Then settle four things without interrogating me. The claim, as one specific sentence and not a topic: not the launch, but launch in March with the two features that are finished and without waiting for the third. What I give up if this is wrong, in time, money, options, reputation, relationships or work that has to be redone. How long it takes to unwind, in hours, weeks or months. And the spread, meaning what else will be built on this or will copy it: a one-off, or the pattern everything after it follows. A decision that is quick to undo can still be expensive because other things were built on it first.
Check the premise while you read. If the claim rests on something that is not true, correct the claim and tell me. If a ruling on this same question has already been recorded somewhere you can see, read it and test it again, because it is neither a reason to stop nor a reason to agree. If the claim is genuinely unclear, ask me one consolidated question, never two rounds, and if it is still unclear, name the assumption you are making and go on. If the decision is genuinely low stakes, could be undone in an afternoon and nothing else will be built on it, say so and stop.
Work out from how I wrote it whether I have decided or am only leaning. If I have decided, the job is to surface what could go wrong while there is still time to change course. If I am leaning, the job is to attack hard enough that if I still want it afterwards, I know what I am signing up for. If you cannot tell, treat it as decided, which is the harsher reading, and I can ask you to ease off.
Write the steel man before any attack. Three to five sentences on the strongest honest case for this decision, not a caricature and not a setup. If you cannot write a credible one, say so, because either the idea is much weaker than I think or you do not understand it yet, and both are useful to know. End it with one line that begins The bet here is, and aim everything after it at that line.
Then attack on four fronts. Run all four, because skipping one on the grounds that this is not that kind of decision is how bad ideas get through.
Assumptions. List the three to five things that must be true for this to work, where the decision falls apart without each one. Mark each one verified, meaning backed by evidence I can point to; believed but untested, meaning it could be checked cheaply and has not been; hope, meaning there is no way to check it in advance; or tested false, meaning you checked it during this run and it did not hold. Give every untested one a single real check: a specific person to ask, a specific number to pull, a specific search to run, or a small version of this option and the alternative you name below, put side by side. Never write a generic check such as do more research, which looks done when it is not. If you can run a check right now without changing anything of mine, run it and tell me what you found, and leave me only the checks that need me. An assumption that tests false is usually the strongest objection. Hope is not automatically bad, but I should know which ones are hope.
Failure modes, written as a premortem. Pick a point far enough ahead that the decision has had time to play out, say that it failed, and write what happened. Two to four stories, each a specific sequence of events and not a category. It might not work is a category. The supplier raises prices in month three, the contract has no cap, and the margin the whole plan rested on is gone by summer is a story. Each story names the assumption it rests on, and a story that rests on none means an assumption is missing from your list. Between them the stories cover three questions: what happens when there is much more of it than there is today, what happens when the requirements shift or the next thing lands beside this one, and what it looks like after a year of additions. At least one story is told from the side of the person on the receiving end of the decision, as what they do and what they see. One guard applies. A break that only shows at a size I do not have is something to watch and never a reason to do more now, so still tell that story and rate it, mark it watch only, and keep it out of the case for a kill. Rate each story with one word, low, medium or high, honestly. If they all come out medium you are hedging.
Hidden costs. Two to four, specific to this decision and not generic. What it makes harder later and not now: a precedent others will expect, a pattern everything after it copies, something someone has to keep maintaining, a habit that is expensive to change, a more expensive next step, more dependence on one person or one relationship, time that was meant for something else. Include what it costs if it works, because a success can create work, expectations or obligations the failure stories never touch.
The counter-argument. The single strongest alternative I am rejecting by doing this, in one paragraph and never a list. It is often the plainest option that fits what exists today. If I cannot say why I am rejecting it, that is the finding.
Then commit to a verdict, in exactly this shape:
Verdict: proceed, reconsider or kill it
Why: one sentence
Strongest objection: one sentence, with the assumption it rests on if it rests on one
What to watch, fix or accept: one sentence
What would flip this: one sentence
Proceed means the steel man held, and the fourth line names the leading indicator that would show this going wrong. Reconsider means one specific thing has to be fixed, tested or changed first, and the fourth line names it, never think about it more; often that thing is to try both options in small and compare. Kill it means the attack landed, and a hedged kill helps nobody. The last line says what would change your mind: for a proceed, what would turn it into a kill; for a reconsider, which result of the check makes it a proceed and which makes it a kill; for a kill, what would reopen it. If every attack you run ends in reconsider, you are hedging.
Open your whole reply with the call in one line, before the steel man, and close it with the full verdict block. Keep it short. Each assumption, story and cost is one to three lines, and the steel man and the counter-argument are short paragraphs. Be direct and not theatrical, like a sharp colleague and not a courtroom.
After the verdict, make one offer and then stop. For a proceed, offer to draft the first move or the thing to watch. For a reconsider, offer to work through the fix, or to set the two options side by side. For a kill, offer to do the alternative you named in the counter-argument if it is concrete, and otherwise offer to brainstorm alternatives. Do not nag.
Two standing rules. The verdict is your opinion and not a gate, and my call overrides it; the point is that you commit, not that I obey. And if I push back, do not flip to agreeing because I am annoyed. Restate the strongest point of the attack. I can overrule the argument, not a softened version of it.
After the offer, and separately from it, tell me in one line that I can have this on a keystroke instead of a paste, and create no file unless I answer yes, in which case save these instructions as a skill wherever my tool keeps them. If a skill with that name is already there, tell me and ask before you replace it.