Twelve Rewrites Is Not The Problem. Twelve Rerolls Are.
A card went round this week with a promise in the headline and a confession in the small print. The headline says “How to master Claude in a week.” Underneath it: “Most people prompt. Few people think with it. This isn’t a prompt guide. It’s a system.” Then two columns, orange against dark green — the average user and the power user — and a four-part framework: Role, Context, Task, Format.
It is a good card. The four parts are real, the examples are sensible, and the pro tip at the bottom is the single most useful sentence on it. But read the orange column and the pro tip together and the card quietly takes back the thing it just sold you.
The source card — “How to MASTER CLAUDE in a week”, BANI Academy. Four-part framework, average-user / power-user split, and a pro tip about collaboration.
The card argues with itself, four inches apart
Here is the left column, word for word:
THE AVERAGE USER. Asks random questions. Gets average answers. Rewrites 12 times. Back where they started.
And the right one:
THE POWER USER. Gives context. Sets direction. Defines structure. Gets better outputs. First draft. Every time.
Now the pro tip, about four inches further down the same image:
Treat Claude like a collaborator. Not a search bar. Not a magic button. The best results come from conversation, iteration, and refinement.
Conversation. Iteration. Refinement. That is rewriting. The card spends its top half mocking somebody for rewriting twelve times and its bottom half telling you that rewriting is where the quality comes from.
This is not sloppiness. It is the card bumping into something true and then stepping around it, because “first draft, every time” fits on a card and the truth does not. The truth is that the number of attempts was never the problem.
Twelve rewrites is fine. Twelve rerolls are not.
What the four parts are actually for
The framework is presented as a recipe. Fill the four slots, get a usable answer on the first try. Read it that way and it will disappoint you, because sooner or later you will fill all four slots properly and the answer will still be wrong.
Read it the other way and it stops disappointing. Role, Context, Task and Format are not four ingredients. They are four named places to change something. Their value shows up on attempt two, not attempt one.
The average user in the orange column does not fail because they rewrite. They fail because every rewrite is a reroll — the whole prompt retyped from scratch, five things different at once, hoping the dice land better. When it works, they cannot say why. When it fails, they have learned nothing. Twelve of those and you really are back where you started, because you have twelve data points and zero information.
The power user does the same number of attempts and calls them something else. They read the symptom in the bad output, decide which of the four parts caused it, change that one, and leave the other three untouched. Attempt two is not another roll of the dice. It is a controlled test with one variable.
That is the whole difference, and the framework is what makes it possible. You cannot change one variable in a prompt that has no named parts.
Diagram: reroll or diagnose
Same person, same task, same number of attempts. Two completely different outcomes.
| Reroll (the orange column) | Diagnose (what the framework enables) | |
|---|---|---|
| What you change | The whole prompt, retyped | One of four named parts |
| Variables moving at once | Three to five, unlabelled | Exactly one |
| What a failure tells you | Nothing. It just failed | Which part was wrong |
| What a success tells you | Nothing. You cannot reproduce it | Which part fixed it |
| Attempt 12 vs attempt 2 | No better — same dice | Narrowed by ten eliminations |
| What carries to the next task | Nothing | A role line, a context block, a format spec you reuse |
| When you stop | When you give up or get lucky | When the symptom is gone |
| Feels like | Arguing with a slot machine | Turning knobs on a desk |
Read the symptom, turn one knob
Here is the part the card does not have room for: a bad output is not just bad, it is bad in a particular way, and the way tells you which part to change. Below, the four parts exactly as the card defines them, matched to the symptom each one actually causes.
| Symptom in the output | Knob | What to actually change | Leave alone |
|---|---|---|---|
| Correct, but shallow. Reads like the first page of a textbook | ROLE | Name the seniority and the domain, not just the job. The card’s own example does this: “a senior product strategist with B2B SaaS experience”, not “a strategist” | Context, Task, Format |
| Right content, wrong register — too formal, too chirpy, too hedged | ROLE | Add who the output is for and in what setting. Tone follows the room, not an adjective | Everything else |
| A good answer to somebody else’s version of your problem | CONTEXT | Your audience, your numbers, your stage. The card says it: your audience, your constraints | Role, Task, Format |
| Keeps proposing things you already ruled out | CONTEXT | State the constraints as facts, not warnings. “Budget is zero” beats “don’t suggest paid tools” | Everything else |
| Plausible, and you cannot tell whether it is what you wanted | CONTEXT | The third thing the card lists and most people skip: what “good” looks like. One sentence of success criteria | Everything else |
| Answers three questions, all of them badly | TASK | Split it. The card is blunt here — one task, one message, don’t bundle | Role, Context, Format |
| Did the last thing you asked, skipped the first | TASK | Same fix. A bundled request is answered in the order it was written and the tail gets the attention | Everything else |
| Content is right, shape is unusable — you have to retype it to use it | FORMAT | Name the container: table with these columns, 80 words, prose not bullets | Role, Context, Task |
| Bullet soup, or three times longer than you need | FORMAT | Say what you want, not what you don’t. Anthropic’s guidance is explicit: “Tell Claude what to do instead of what not to do” | Everything else |
| Obeys for one message, then drifts back to default | ROLE, wrong place | The role belongs where it persists, not retyped each turn — a system prompt, project instructions, or a CLAUDE.md | Everything else |
| Stated a fact that is not true | None of the four | No knob fixes this. Supply the source or accept you have to check it. See the caveats below | — |
Two things fall out of that table once it is written down.
The first is that three of the eleven common symptoms are Context problems, and the one people skip most — what “good” looks like — is the one that causes the most frustrating failure, the output you cannot grade. The card lists it third in the Context box, in the smallest text on the card. It deserves to be bigger.
The second is that the knobs are not equally expensive. Changing Format costs you six words and is almost always safe. Changing Task means admitting you asked for two things. Changing Context means you have to go and work out what your constraints actually are, which is why people change Role instead — it is the fun one, and it is rarely the problem.
Four parts out of six
Anthropic publishes its own prompting guidance, and it is worth putting the card next to it, because the card is not wrong — it is short. Under General principles, the prompting best practices page lists five techniques, and a sixth sits under output formatting. The card has four of the six.
| Anthropic’s principle (page order) | On the card? | What it is | What the card’s four do not cover |
|---|---|---|---|
| Be clear and direct | Yes — TASK | “Be specific. One task. One message. Don’t bundle.” The docs put it the same way: think of Claude as a brilliant but new employee who lacks context on your norms | — |
| Add context to improve performance | Yes — CONTEXT | Audience, constraints, what good looks like. The docs add a wrinkle the card misses: explain why, not just what | The card asks for facts. The docs ask for motivation too |
| Use examples effectively | No | Few-shot prompting. The docs call examples “one of the most reliable ways to steer Claude’s output format, tone, and structure”, and suggest three to five | This is the big one. See below |
| Structure prompts with XML tags | No | Wrapping instructions, context and input in their own tags so a long prompt cannot be misread as one blob | Matters the moment your prompt has pasted material in it |
| Give Claude a role | Yes — ROLE | The docs are specific about where: “setting a role in the system prompt”, not retyped in each message | The card says what to write, not where to put it |
| Control the format of responses | Yes — FORMAT | Bullets or prose, table or code. The docs add: say what to do, not what to avoid | — |
Both missing parts are the ones that show instead of tell. Role, Context, Task and Format are all descriptions. You write sentences about what you want. Examples and XML tags are not descriptions — an example is a finished thing you hand over, and a tag is a container you put material into. The card’s framework is entirely made of talking about the output. Neither of the two things it omits involves talking about the output at all.
That matters most for Format, the knob people reach for first. You can spend three sentences describing the shape you want, or you can paste one short piece you already like and say “this shape”. The second is shorter and lands better, and it is the one the card has no slot for.
One honest note on ordering: Anthropic’s page does not present that list as a ranking, so nobody should claim role matters least. But it is worth noticing that the item the card numbers 1 is the one the documentation reaches last, and the two it leaves out sit in between.
And then there is the line at the top of Anthropic’s prompt engineering overview, which tells you what the whole discipline assumes you already have: a clear definition of success criteria, a way to test against them, and — the phrase worth reading twice — “a first draft prompt you want to improve”.
A first draft you want to improve. Not a first draft, every time. The best-practices page says the same thing about workflow: the most common chaining pattern is self-correction — draft, review against criteria, refine. Iteration is not the failure mode. It is the documented method.
A week, a weekend, or tonight
The card gives three different deadlines for the same thing, and it does it in three places you can see at once.
- The headline: master Claude in a week.
- The caption above the image: master the basics in one weekend.
- The last line of the card: start tonight.
It would be easy to call that careless. It is more interesting to take it seriously, because all three are defensible and that is exactly the tell. There is no syllabus here. Nothing on this card takes a week to learn. You can read the four parts in ninety seconds and you will not have mastered anything, because what the card is actually teaching is a habit — change one thing, see what moved — and a habit does not have a completion date.
So take the smallest of the three. Tonight, one real task you were going to do anyway. Write the prompt with the four parts named, even roughly. When the output is wrong, do not retype it. Say out loud which of the four was wrong, change that one, and run it again. Three attempts is enough to feel the difference between a reroll and a diagnosis.
If you want the slots themselves filled out in more detail than a card allows, we have written them up twice before from different angles: the five slots that turn a prompt into a usable answer covers what goes in each one, and fifteen short phrases that stack covers which additions combine and which cancel each other out. This post is the other half: not what to write the first time, but what to change the second time.
Four things no knob fixes
Being fair to the card means also being clear about where its framework stops.
- “90% of its power” is a slogan, not a measurement. The caption says you are leaving ninety per cent of Claude’s power on the table. Nothing on the card sources that number and there is no public benchmark it could come from. The underlying point — that most people use a fraction of what is there — is fair. The figure is decoration.
- No knob fixes a wrong fact. Role, Context, Task and Format steer shape, framing and tone. If the model states something untrue, turning any of the four will produce a better-dressed version of the same error. That is a sourcing problem: give it the document, or check the claim yourself.
- Prompting is not always the right lever. Anthropic’s own overview makes the point that not every failing result is best solved by prompt engineering — it gives latency and cost as cases where picking a different model is the easier fix. Worth remembering before attempt thirteen.
- A knob you cannot read is not a knob. The whole method above assumes you can tell a good output from a bad one. If you cannot — if the answer is in a field you do not know well — then no amount of turning helps, because you have no signal. That is a separate job, and we have written about why the thing that makes the output can never be the thing that grades it.
One more, smaller: the symptom-to-knob table above is our reading, not the card’s and not Anthropic’s. The four parts come from the card and the six principles come from the documentation; the mapping between a bad output and the part that caused it is ours, assembled from the way these failures usually show up. Treat it as a starting heuristic and override it the moment your own evidence disagrees.
And on Role specifically: the documentation says to put it in the system prompt, which the plain chat box does not give you. The nearest equivalents are project instructions, a custom style, or a CLAUDE.md file — places a role is stated once and stays stated. If you find yourself retyping “act as a senior…” every morning, that is what a project is for.
The one-line version
The card’s two columns are not two kinds of person. They are two kinds of second attempt. The average user rerolls; the power user turns one knob and watches. Role, Context, Task and Format are worth learning not because they get you a first draft every time — they will not — but because they are the only reason your twelfth attempt can be smarter than your first.
Try it tonight. One task. Four parts, named. Then three attempts where you change exactly one of them each time and say which, out loud, before you hit enter.
