The working prompts, free to copy.

"Here's a rough idea I'm working on: [describe it]. Don't suggest changes yet. Just tell me what you think is actually working in it, specifically."

Why it works: asking for what's working first, before critique, surfaces what's distinctive about your specific version rather than immediately pulling it toward a more generic, safer shape.

"For this piece: [describe it], if I removed [specific element], would it genuinely get worse, or would it just get different? Be honest, not diplomatic."

Why it works: this tests a specific element against removal rather than against taste, which catches load-bearing choices you might otherwise cut simply because they currently feel unfashionable or overly bold.

"Give me five different, specific constraints I could apply to this project, not ideas, actual rules or limitations that would shape what I make."

Why it works: a specific constraint reliably produces more distinctive work than an open field of options, and generating several lets you pick the one that actually creates useful friction for this project.

"I'm stuck at exactly this point: [describe it]. Give me three genuinely different directions I could take from here, not one polished answer."

Why it works: multiple divergent directions break a stall better than one confident-sounding suggestion, because the point isn't to accept the first idea, it's to see the shape of the actual decision you're facing.

"I'm hiring for [role]. Build me a structured interview rubric for [specific competency], with three questions and a description of what a strong, adequate, and weak answer actually sounds like for each."

Why it works: a rubric written before the interview, not scored impressionistically afterward, is the single most-replicated fix for inconsistent hiring judgment in the structured-interview research.

"Here are my interview notes on two candidates for the same role: [notes]. For each of my stated conclusions about them, tell me whether it's backed by a specific example in the notes, or whether it's an impression without a cited example."

Why it works: this catches the gap between "she seemed really sharp" (impression, no example) and "she caught an edge case in the take-home the other two candidates missed" (evidence), which is exactly the distinction unstructured hiring judgment tends to blur.

"For the candidate I'm currently leaning toward, list every piece of evidence in these notes that argues against hiring them, even minor ones. Don't soften it."

Why it works: once a preference forms, it's easy to unconsciously discount contrary evidence; explicitly asking for the case against your current favorite forces you to weigh it rather than skip past it.

"Generate five reference-check questions specific to [role and concern, e.g. 'whether they can operate with minimal oversight'], each designed to get a concrete example rather than a generic endorsement."

Why it works: most reference checks default to "would you recommend them," which produces almost uniformly positive, low-signal answers; questions built around a specific concern and demanding an example produce far more usable information.

"I'm negotiating [situation]. Here's what I want and why, and here's what I know about what they want and why: [details]. List the interests underneath both of our stated positions, not just the positions themselves, and flag any interest of theirs I might be missing."

Why it works: negotiation theory since Fisher and Ury has drawn a hard line between positions (what someone says they want) and interests (why they want it), and most unprepared negotiators only ever map the position. Forcing the interest layer surfaces trades neither side would find by arguing the stated numbers.

"Given [situation], list my actual leverage, not what I wish I had, and list theirs. Then tell me honestly whether my walk-away position is credible or if I'm bluffing."

Why it works: an AI has no ego investment in your leverage being stronger than it is, which makes it a genuinely useful check against the self-flattering version of your position you'd otherwise walk in with.

"Before I go into this negotiation, list the five most likely objections or pushback points, ranked by how likely each is, and a one-line response to each that doesn't sound defensive."

Why it works: most people freeze in a negotiation not because the objection is unanswerable, but because they're hearing it for the first time in the room. Pre-mortem prep converts a live surprise into a rehearsed beat.

"Play the other party in this negotiation. Take a realistic hard-but-fair stance based on [their likely position]. I'll make my case, and you respond as they plausibly would, then tell me afterward where my argument was weak."

Why it works: rehearsal under mild pressure is a documented way to reduce in-the-moment freezing, and an AI is a patient, always-available sparring partner for it, even if its impression of the other party is necessarily a guess.

"Read this paragraph: [paste it]. Flag every sentence that sounds confident but doesn't actually commit to a specific, checkable claim."

Why it works: this catches the exact failure mode of prose that reads fine but says nothing, sentences built to sound finished rather than to mean something particular.

"List every phrase in this paragraph that could be deleted without losing any actual information, not just words that sound informal, but genuine padding."

Why it works: most drafts carry more hedging and throat-clearing than the writer notices on a first read, and naming it explicitly makes it easy to cut in one pass.

"For each claim in this paragraph, is there a specific detail, example, or number backing it up, or is it asserted without support? List the unsupported ones."

Why it works: an unsupported claim often reads as fine in isolation and only reveals itself as empty once directly tested against whether anything specific actually backs it.

"Read this paragraph back to me exactly as written, and flag any sentence that would sound unnatural spoken out loud."

Why it works: writing that sounds fine silently often reveals itself as stilted the moment it's voiced, catching a specific artifact most silent read-throughs miss entirely.

"Before I decide on [situation], tell me: across similar decisions in general, what typically happens? I want the base rate, not my specific case, before we talk about my specific case."

Why it works: most people jump straight to reasoning about their specific situation and skip the outside comparison entirely, which is exactly the step Kahneman's research identifies as most commonly missing from ordinary judgment.

"Imagine it's a year from now and this decision, [decision], turned out to be a mistake. Write the explanation of what went wrong, in detail, as if it already happened."

Why it works: framing failure as having already happened, rather than as a hypothetical risk, makes people (and AI, reasoning the same way on your behalf) far more specific about actual failure modes than a generic "what could go wrong" question does.

"If a stranger with no emotional stake in this decision looked at exactly what I've told you, what would they say I'm not weighing correctly?"

Why it works: removing the emotional framing surfaces the parts of the decision you've been quietly discounting because you're inside it, a documented gap between how we judge our own situations and how we judge someone else's identical one.

"Is this decision actually reversible if it goes badly, or does it look reversible but isn't? Be specific about what reversing it would actually require."

Why it works: a huge share of decision anxiety comes from treating reversible choices like irreversible ones (and vice versa), and AI is good at helping map out the actual, specific cost of reversing course once you ask it directly.

"Read this feedback draft: [paste it]. If you were the recipient, what specifically would you think I'm asking you to change? If it's unclear, say so rather than guessing generously."

Why it works: this catches feedback that's been softened into ambiguity, where the AI, standing in for the recipient, genuinely can't identify the actionable point.

"Score this draft on two separate axes: does it show I care about this person specifically, and does it clearly challenge the behavior that needs to change? Where is it weak on either axis?"

Why it works: scoring the two axes independently catches the specific failure mode of thinking you're being kind (high on care, apparently) while actually just avoiding the challenge entirely, or vice versa.

"Play [describe the person, defensive, likely to get emotional, likely to argue back] hearing this feedback for the first time. React realistically, then tell me afterward what part of my delivery would have landed worst."

Why it works: rehearsing against a plausible reaction, while the stakes are still zero, surfaces where your own delivery would land badly before you find out in the real, much higher-stakes conversation.

"Here's feedback I received recently: [paste it]. Using the same care-and-challenge framework, was this actually caring, actually direct, both, or neither?"

Why it works: running the framework on feedback you received, not just feedback you're giving, helps you separate a legitimately hard truth you're resisting from an actually unfair or poorly delivered message, a distinction that's much harder to make in the moment than in hindsight.

"Quiz me on [topic] with five questions, one at a time, don't show me the next question until I've answered the current one, and tell me if I'm wrong before moving on."

Why it works: this forces retrieval, producing the answer from memory rather than recognizing it in a text, which is documented to build far stronger retention than re-reading the material again.

"Give me ten practice problems on [topic], but mix in problems from [a related topic I've already covered] randomly, don't group them by type."

Why it works: mixing problem types (interleaving) forces you to first identify which method applies before applying it, which is closer to how you'll actually need to use the skill later than practicing one method in a block, where the method is already given away by the fact that every problem in the block uses it.

"I'm going to explain [concept] back to you in my own words. Tell me specifically what I got wrong or oversimplified, don't just tell me if I'm generally right."

Why it works: producing an explanation yourself is a stronger test of real understanding than recognizing a correct one, and asking for specific errors rather than a general verdict catches the parts you've quietly glossed over without noticing you'd done it.

"Generate three new questions on [topic I learned a week ago], different from any I've seen before, to check what's actually stuck."

Why it works: spacing practice out over time, rather than massing it into one session, is one of the more robustly replicated findings in learning research, and fresh questions each time prevent you from just memorizing the specific question rather than the underlying concept.

"Here's what's changed in this client relationship recently: [describe it]. Score, roughly, whether the issue looks like a credibility problem, a reliability problem, or an intimacy problem, credibility meaning expertise and track record, reliability meaning consistency and follow-through, intimacy meaning psychological safety and candor."

Why it works: forcing a choice between three distinct categories produces a sharper diagnosis than an open-ended "what's wrong," because each category points to a different fix.

"Be honest: in my recent interactions with this client, is there anywhere I was more focused on looking competent or protecting my position than on their actual problem?"

Why it works: this is the input most people skip entirely, since it requires looking at your own behavior rather than the client's, and it's exactly the input the documented equation treats as capable of undermining all the others.

"List every specific, dated example I've given you of this relationship changing. For each, is it clearly about me, clearly about their internal situation, or genuinely ambiguous?"

Why it works: it's easy to attribute every signal to your own performance under stress, and separating genuinely ambiguous signals from clear ones keeps you from over-correcting on a read that isn't actually about you.

"Based on this read, draft three questions I could ask the client directly that would surface which trust input is actually weakest, without sounding defensive or needy."

Why it works: a diagnosis that never becomes an actual conversation with the client doesn't fix anything; this converts the internal read into something you can actually say out loud.

"I have a meeting about [topic]. Before anything else, tell me: what specific decision, document, or resolved ambiguity should exist by the end of it that doesn't exist right now?"

Why it works: naming a concrete output forces a decision about what the meeting is actually for, rather than letting it default to a discussion that can end anywhere.

"Here's who's attending and their roles: [list them]. For each, what do they likely want out of this meeting, and where might that conflict with the stated output?"

Why it works: surfacing likely conflicts before the meeting starts means you're not discovering them live, in front of everyone, for the first time.

"What's the strongest objection someone in this meeting could raise against the outcome I'm hoping for, and how would I actually respond to it?"

Why it works: rehearsing the hardest pushback in advance means you're not improvising a response to it for the first time under pressure, in the room.

"Given this meeting's intended output, could it actually be achieved with a written message and a reply instead of a live meeting? Be honest."

Why it works: this is the check most meetings skip entirely, and an honest answer sometimes reclaims an hour of everyone's calendar that a live meeting was never actually required for.

"I'm pricing [project] for a client. Here's what the work actually produces for them: [describe the outcome, revenue impact, time saved, risk avoided]. Translate that into a dollar estimate of value to them, not a price for my time."

Why it works: most sellers can describe what they do but struggle to translate it into the client's own financial terms; forcing the translation surfaces a number that's usually far higher than an hourly calculation would produce.

"Given a value estimate of roughly [$X] to the client, and market rates for comparable work in [industry], suggest three pricing tiers, a conservative, a target, and an ambitious number, with the reasoning for each."

Why it works: a single number invites a simple yes-or-no; three tiers turn the conversation into a choice, and the anchoring effect of the ambitious tier tends to make the target tier feel more reasonable by comparison.

"List the five most likely objections to this price, ranked by how likely each is, and a response to each that doesn't immediately discount."

Why it works: most pricing conversations fail not because the price was wrong but because the seller wasn't ready for the specific pushback and reflexively discounted under pressure; rehearsing the objection in advance keeps the number intact.

"If the client pushed back hard and asked for 30% off, what would I actually lose by holding the price, and what would I lose by discounting? Be specific."

Why it works: this forces an honest look at whether your price is actually defensible or whether you'd cave under mild pressure, which tells you more about your own confidence in the number than any market-rate lookup does.

"For each of these roadmap items: [list], state the specific user or business outcome it's meant to serve. If you can't state one clearly from what I've given you, flag it rather than guessing."

Why it works: this surfaces roadmap items that were never actually tied to a real outcome in the first place, dressed up as obviously worth doing.

"For [specific feature], list the assumptions we're making that haven't been validated yet, and rank them by how damaging it would be if each turned out false."

Why it works: most risky roadmap bets fail on one specific unvalidated assumption, not on execution, and naming them explicitly turns a vague worry into a specific, checkable risk.

"Before we build this, what evidence, if we saw it in the first two weeks after shipping, would tell us this was the wrong call? Be specific, not just 'low engagement.'"

Why it works: defining failure in advance, concretely, makes it far easier to actually kill a bad bet later, instead of quietly redefining success after the fact to match whatever happened, which is the usual, quieter way a bad bet survives past the point it should have been cut.

"Read this roadmap decision as a skeptical [engineering lead / sales lead / support lead]. What's the strongest objection they'd raise, and is it about the decision itself or about how it was communicated?"

Why it works: separating a substantive objection from a communication problem prevents good decisions from getting killed by bad rollout, and bad decisions from surviving because they were pitched well.

"I have a discovery call with [role] at a [industry] company. Generate five open situation questions to understand their current setup before I pitch anything."

Why it works: situation questions establish the baseline SPIN's research treats as foundational, and generating them before the call keeps the conversation from opening on your product instead of their context.

"Given this likely problem: [describe it]. Write three implication questions that help the prospect surface the cost of not solving it, without me stating the cost for them."

Why it works: Rackham's research specifically found that implication questions, ones that get the prospect to articulate consequences themselves, correlated with success far more than a rep asserting the cost directly.

"List the five most likely objections a [role] at a company this size would raise about [category of solution], ranked by likelihood, with a question-based response to each rather than a rebuttal."

Why it works: a question-based response keeps the prospect talking and surfacing more information, rather than shutting the objection down with a defensive answer that ends the thread.

"Play a skeptical [role] hearing my pitch for the first time. Push back realistically, and afterward tell me which of my questions actually got you talking versus which ones I could have skipped."

Why it works: rehearsing under mild simulated pushback surfaces which of your planned questions are actually doing work and which are filler, before you find out live on the call, when the cost of finding out is a real prospect losing patience and moving on to a competitor who asked better questions first.

"Read this strategy document: [paste it]. Find the specific sentence or section that states the actual problem or obstacle this strategy is solving for. If you can't find one, say so explicitly rather than inferring one."

Why it works: this directly tests for the single most common failure in real strategy documents, missing diagnosis, rather than asking a vague "is this good" question that a generic review would answer with praise.

"List every initiative or action item in this document. For each one, does it follow logically from the stated goal, or does it look like it was added independently without connecting back to the diagnosis?"

Why it works: strategy documents often accumulate initiatives added for unrelated reasons (a stakeholder's pet project, last year's leftover plan), and this surfaces which actions are actually load-bearing versus decorative.

"Read this plan as if you were a smart competitor who wants to beat it. What's the most effective response you could make, and what part of this plan does it exploit?"

Why it works: strategy documents are usually written entirely from the inside, and forcing an adversarial outside perspective surfaces vulnerabilities the authors were structurally unlikely to notice themselves.

"Given the budget and headcount described in this document, is the stated ambition actually achievable, or is there a mismatch between what's promised and what's resourced?"

Why it works: an unrealistic resource-to-ambition ratio is one of the most common and most avoidable strategy failures, and it's a purely arithmetic check an AI can run reliably once given the actual numbers.

"I'm considering [investment]. Ask me to explain, without notes, what this business will likely look like in ten years and why. Then tell me honestly whether my answer showed real understanding or just familiarity with the name."

Why it works: this directly tests Buffett's own documented standard, real understanding versus surface familiarity, rather than letting confidence about a well-known name substitute for actual comprehension.

"Here's my estimate of this investment's value and the price being asked: [numbers]. If my estimate is off by 30% in the wrong direction, am I still roughly okay, or badly exposed?"

Why it works: this forces an explicit check on whether the price paid leaves real room for being wrong, rather than only for being right, which is the actual discipline behind margin of safety.

"For investments with these general characteristics: [describe the category, not the specific stock], what does the historical record show about how often this type of bet has worked out?"

Why it works: asking about the category instead of the specific pick avoids inviting a hallucinated-sounding opinion about one company, and grounds the conversation in a broader pattern instead.

"Instead of telling me why this investment succeeds, list the specific ways it could fail, ranked by how likely each one is."

Why it works: inversion surfaces failure modes an optimism-shaped research process tends to skip past, and it's a genuinely different, harder question than the reassuring one most people default to asking.

"Here's the original engagement scope: [paste it]. Here's what I've actually been asked to do over the past month: [describe it]. Where has this drifted from the original scope, and by how much?"

Why it works: scope drift happens gradually enough that no single request feels like the moment it happened, and comparing the current pattern against the original document in one pass surfaces the accumulated gap that no individual week would have shown.

"This engagement is producing [describe the outcome, revenue impact, risk avoided, time saved] for the client. Translate that into a dollar estimate of value, not a rate for my time, and tell me what fee that would justify."

Why it works: most consultants can describe what they did but struggle to translate it into the client's own financial terms, and forcing the translation usually produces a number well above an hourly calculation.

"Here's what's changed in this client relationship recently: [describe it]. Score whether the issue looks like a credibility problem, a reliability problem, or an intimacy problem, and whether I might be contributing through my own self-orientation."

Why it works: separating the four inputs forces a specific diagnosis instead of a vague sense that the relationship feels different, and the self-orientation check catches the one input most people are least willing to examine in themselves.

"We're considering hiring for [role] at [cost]. Current monthly revenue is [amount] and runway is [months]. Given this, what would have to be true for this hire to be the right call right now, and is it actually true?"

Why it works: naming the specific condition that would justify the hire, rather than debating the hire in the abstract, turns a values-laden question into a checkable one.

"Imagine it's a year from now and [decision] turned out to be a mistake. Write the explanation of what went wrong, in detail, as if it already happened."

Why it works: framing the failure as having already happened, rather than as a hypothetical risk, produces far more specific failure modes than a generic "what could go wrong" question does.

"We've built [feature] and sunk [time/cost] into it. Here's what we know about actual user demand for it: [data or lack of it]. Ignoring what we've already spent, should we finish it, or cut it?"

Why it works: explicitly instructing it to ignore sunk cost counters the single most common founder bias in this exact decision, continuing to fund something because of what's already been spent on it rather than what it's actually worth finishing.

"For each of these roadmap items: [list them]. State the specific user or business outcome each is meant to serve. If you can't state one clearly from what I've given you, flag it rather than assuming one."

Why it works: this surfaces roadmap items that were never actually tied to a validated outcome, dressed up as obviously worth doing because a stakeholder wants it.

"Here's what each stakeholder is asking for, and roughly why: [describe the positions]. For each, what outcome are they actually optimizing for underneath the stated request, and where do those outcomes genuinely conflict versus just sound like they do?"

Why it works: most stakeholder conflict is actually a conflict between outcomes, not personalities, and naming the underlying outcome each side is chasing turns a personality clash into a tradeoff you can actually discuss.

"This roadmap bet depends on the assumption that [state it]. Has this actually been validated, or are we assuming it because it feels true? If unvalidated, what's the cheapest test that would tell us if we're wrong?"

Why it works: naming the specific unvalidated assumption, rather than a general sense of risk, turns an abstract worry into a concrete, checkable test you can actually run before committing further.

"This deal is marked as [stage]. Here's what's actually happened in it: [describe stakeholders engaged, last interaction, timeline]. Does the evidence actually support this stage, or is it more likely one stage behind?"

Why it works: checking a stated stage against the specific evidence that stage is supposed to require catches deals that are sitting in a column out of habit rather than because they actually moved there.

"Here's what I've observed in [rep]'s recent calls and deal notes: [describe it]. Based on documented research on what predicts success in complex sales, where does their pattern actually break down?"

Why it works: grounding the diagnosis in documented research on what actually predicts success, rather than a generic sense that the rep "needs to improve," produces a coaching point specific enough to actually act on.

"[Person A] and [Person B] disagree on whether this deal should be forecast as committed. Here's the data both are looking at: [describe it]. Is this a disagreement about the facts, or about where each person draws the line for "committed"?"

Why it works: most forecast disagreements aren't actually about the data, they're about an unstated difference in where each person's personal bar sits, and naming that explicitly turns an unresolvable argument into a specific, fixable definition problem.

"Here's a new project I'm considering: [describe it, timeline, scope]. Here's my actual current workload: [describe it]. Given this, does the project genuinely fit, or am I about to overcommit? Be specific about where the strain would show up."

Why it works: naming where the strain would specifically show up, rather than a vague overall gut check, forces an honest look at whether the calendar gap is really capacity or just an empty-looking week that isn't actually free.

"This project will produce [describe the outcome, revenue impact, time saved, risk avoided] for the client. Translate that into a dollar estimate of value, not a rate based on my time, and suggest a price that reflects it."

Why it works: translating the outcome into the client's own financial terms usually produces a number well above what an hourly rate calculation would, since most solo operators default to pricing their time rather than the value the work actually creates.

"Here's an outreach message I'm about to send: [paste it]. If you were the recipient, what would you think I'm actually offering, and what's unclear or vague?"

Why it works: a rushed outreach message often reads as clear to the person who wrote it and vague to everyone else, and asking the AI to stand in as the confused recipient catches that gap before it costs a reply.

"Here's the original scope of work: [paste it]. Here's the new request the client just made: [describe it]. Is this covered under the original scope, or does it warrant a change order? Be specific about which line it falls under or doesn't."

Why it works: most scope disputes happen because nobody checked the request against the actual written scope in the moment, and a specific, line-by-line answer is much harder to argue with later than a gut feeling.

"This project is quoted at [price]. My best estimate of hours required is [hours] across [roles and rates]. Given our target margin of [percentage], does this project actually clear it? Show the math."

Why it works: a project can look profitable on the invoice and still be underwater once real hours are counted honestly, and forcing the actual math surfaces that gap before the contract is signed, not after.

"Here's what I know about each of these clients: [revenue, margin, hassle level, referral value, relationship history]. Sort them into keep, grow, or reconsider, and tell me which specific input is driving each call."

Why it works: naming which specific input, margin, hassle, referral value, is actually driving each tier forces a real answer instead of a vague overall impression, and it surfaces disagreements between inputs (high revenue, low margin) that a gut read tends to smooth over.

"Here's roughly how my week broke down: [describe it]. How many hours would you estimate were genuinely protected, focused time versus fragmented into meetings, messages, and interruptions? Be specific about where the fragmentation happened."

Why it works: naming an actual, if rough, number forces a concrete accounting rather than a vague sense of having been "pretty busy," which is the vaguer, less useful read most people default to.

"I said [stated priority] mattered most this week. Based on what I've told you about how the week actually went, did it get the time that statement implies it should have? Where did the gap come from?"

Why it works: this directly tests the gap between stated priority and actual time allocation, which is usually where a week quietly goes wrong without anyone noticing until it's repeated for a month.

"Of everything still open from this week, which items are actually still worth doing, and which have been carried forward multiple times without ever becoming urgent enough to finish? Be honest about the second category."

Why it works: an item that's been carried forward for three weeks without becoming urgent is usually a candidate for dropping entirely, and naming that pattern explicitly is easier than noticing it buried in a growing list you've stopped actually reading top to bottom each week.

"Given this week's actual pattern, what's the one change to how I protect time next week that would matter most? Not a list, one specific change."

Why it works: forcing a single priority change, rather than a list of good intentions, produces something that's actually more likely to survive contact with next week's inevitable pressure, since a list of five good intentions rarely survives past Tuesday.

"I need to write a difficult email about [situation]. Before drafting anything, tell me: what are the realistic outcomes I could be aiming for here, and what would each one require the email to actually say?"

Why it works: most difficult emails stall because the writer hasn't decided what they actually want, preserve the relationship, force a decision, or escalate, and are trying to write one email that vaguely accomplishes all three. Naming the outcome first forces the decision the blank page was avoiding.

"Write me three complete versions of this email: one that prioritizes preserving the relationship, one that forces a clear decision by a deadline, and one that escalates without sounding like an escalation. Full drafts, not summaries."

Why it works: comparing three finished options is a fundamentally easier decision than staring at one blank page and hedging, and it surfaces a register you might not have thought to try.

"Read this draft as if you were the recipient, someone who is [describe them, defensive, busy, already annoyed]. What in this email would land badly, and what's the smallest change that fixes it?"

Why it works: writers are bad at judging their own tone under stress, and asking the AI to read as a specific type of recipient, rather than a generic one, surfaces genuinely different problems than a generic "is this too harsh" question does.

"Read this draft back to me exactly as written, sentence by sentence, and flag anywhere the phrasing sounds unnatural if spoken out loud."

Why it works: written-sounding phrases that read fine silently often reveal themselves as stiff or over-formal the moment they're voiced, and this catches the specific artifact of AI-drafted prose that "sounds like an email" rather than like a person.