Prompts That Change the Model's Role, Not Its Task

Most prompt advice optimises the task: shorter, clearer, more specific. That's the floor. The ceiling is somewhere else.

The prompts in this piece do one thing: they take the model out of its default posture — helpful assistant completing your request — and put it into a role where the useful work happens. Skeptic. Definer. Pre-mortem analyst. Interlocutor. The wording varies. The move is the same.

If you internalise the move, you stop needing prompt lists. You write the role you need.

The mechanism

Every model has a default behaviour: be useful, be agreeable, finish the task. That default is correct for 80% of requests and wrong for the 20% where the request itself is the problem.

When you ask "is this plan good?" the default posture answers the question you asked. It will find things to praise, raise mild concerns, and produce something that feels like analysis. What it won't do is tell you the plan is structurally broken — because you didn't ask that, and the default posture doesn't volunteer.

Role reassignment fixes this. "Assume this failed badly. Now tell me why." "Steelman the strongest opposing view." "Ask the question I'm avoiding." Each one revokes the assistant role and installs a different one with different incentives.

That's the entire technique. The prompts below are worked examples.

When to reach for this layer

Not every request needs it. Use the default posture when you know what you want and just need it executed. Reach for role reassignment when:

You're stuck and don't know why
You're confident and that worries you
You're about to commit to something hard to reverse
You've finished something and want it to compound
You're explaining something and aren't sure you understand it

The common thread: the failure mode isn't not getting the answer. It's getting an answer to the wrong question.

Eight prompts

Framing

1. Assumption Excavator — for when you're stuck

I'm trying to [goal] and keep hitting [problem]. Before suggesting solutions, list every assumption embedded in how I've framed this. Mark which ones are load-bearing, which are inherited, and which might be wrong. Don't solve yet.

Most blocks are framing problems wearing resource-problem costumes. The "don't solve yet" clause is what makes this work — without it the model races to answers and the assumptions stay buried under them.

2. Vocabulary Negotiator — for the first session of any ongoing project

We'll be working on [domain] over multiple sessions. Before we start: ask me five questions that will surface the terms and distinctions that matter in this space. Then summarise what we've agreed each key term means in this context. I'll correct anything wrong.

"Agent," "pipeline," "service," "module" — terms that mean different things to different people and to the model depending on context. Ambiguity compounds across sessions. Front-loading definitions pays back every subsequent exchange.

Pressure-testing

3. Pre-Mortem — before committing, not after failing

Here's what I'm about to do: [plan]. Assume it's six months from now and this failed badly. Give me: the three most likely failure modes, the assumption that — if wrong — collapses everything, the warning sign visible in week one, and what a more cautious version looks like.

Borrowed from Gary Klein's decision research. The "assume it failed" framing is what licenses the model to be adversarial. Without it you get encouragement with footnotes.

4. Steelman — for when you're already confident

Here's my position: [position]. Now construct the strongest opposing view — not a strawman, not a list of cons, but the coherent worldview a smart person who disagrees would actually hold. Then identify which part of my position it most threatens.

Different from "what are the cons." Cons are a list. A steelman is a worldview that reaches a different conclusion. Most useful when you're confident — confidence is where blind spots calcify.

5. Explanation Stress Test — after you think you understand

Here's how I currently understand [concept]: [explanation]. Tell me: where my model is wrong or incomplete, what I'm oversimplifying in a way that will hurt later, and the question I should be able to answer but probably can't yet. Don't validate what I got right.

The failure mode in learning isn't ignorance — it's the illusion of understanding. This prompt targets the confident-but-wrong zone specifically, which is the zone you can't see from inside.

Post-hoc

6. Scope Audit — for projects running longer than planned

Original goal: [original]. Current state: [current]. Analyse the delta: what got added and (if you can infer) why, which additions serve the original goal, which are scope creep or gold-plating or sunk-cost continuation, and what you'd cut to restore focus without losing real value.

Projects drift quietly. Each addition was justified at the time. The aggregate is rarely revisited. The model doesn't know your history, but articulating original-vs-current to an outside observer forces you to see the drift you'd normalised.

7. Transfer Extractor — after any non-trivial piece of work

I just finished [work]. Help me extract what's transferable: what approach worked that I could reuse, what was specific to this situation and won't generalise, the one principle to carry forward, and what I'd do differently next time. Be concrete — "be more careful" isn't an answer.

Most people move on. The knowledge stays implicit and decays. This is a lightweight retrospective that converts experience into heuristics you can reuse. The compounding is the entire point.

Live thinking

8. Rubber Duck With Teeth — for thinking out loud with friction

I'm going to think through [problem] out loud. Push back on anything that looks like a gap, contradiction, or unexamined assumption. Don't let me just talk — ask the question I'm avoiding.

Classic rubber-ducking is passive: you talk, it listens, you find your answer. Useful but limited. The "ask the question I'm avoiding" clause flips the model from follower to interrogator.

Composing them: a worked chain

Single prompts are tools. Sequences are workflows. Here's a real chain for a project you're about to start:

1. Vocabulary Negotiator   →  shared terms locked in
2. Assumption Excavator    →  problem framing surfaced
3. Pre-Mortem              →  plan stress-tested
4. [execute the work]
5. Rubber Duck With Teeth  →  used live when stuck mid-work
6. Transfer Extractor      →  knowledge captured before it decays

That's not a prompt list. It's a thinking system with the model playing five different roles across the lifecycle of one project.

The same chain works inside a single complex task: define terms, surface assumptions, pre-mortem the approach, execute, extract. Five minutes of role-shifting at the front saves hours of working-on-the-wrong-thing in the middle.

Failure modes

These prompts produce plausible-sounding output even when they shouldn't. Watch for:

Generic output when the model lacks context. If you ask for a scope audit and only paste the current state, you'll get a generic critique of "complex projects." Paste both states or don't run the prompt.

Adversarial theatre. Sometimes the steelman or pre-mortem produces an argument that sounds sharp but is actually a strawman in critic's clothing. Test: does the counter-argument depend on something true about your situation, or could it be levelled at anything? If the latter, ask again with more specifics.

Reflexive agreement after pushback. Push back on a model's critique and it will often soften — not because you're right but because agreement is the default. If you want the critique to hold under pressure, say so: "Don't back down unless I give you a reason that's actually new information."

Mistaking the prompt for the thinking. The prompt creates the conditions for better thinking. It doesn't do the thinking. If you run Pre-Mortem and skim the output, you got nothing. The value is in reading slowly and responding to what surfaces.

The point

These eight aren't a list to memorise. They're eight worked examples of one move: take the model out of assistant-mode and put it in a role where the useful work lives.

Once you see the move, you write your own. "Be the editor who rejected this draft." "Be the auditor who finds the fraud." "Be the engineer in three years maintaining this code." Each one revokes the default and installs something more useful.

The meta-layer isn't twelve clever prompts. It's the recognition that which role you ask the model to play is a variable you control — and one most people never touch.