nanda mochammad
Applied AI

Prompting for general tasks: common mistakes and how to fix the answer

9 min read
Tagged AI

You paste a report into the chat box and type “summarise this.” Back comes five bland bullet points that could describe almost any report, nothing you can use in the meeting you’re prepping for. Or you type “write me an email to my landlord” and get a stiff, generic note that doesn’t mention the broken heater, the date, or the fact that you’ve already emailed twice. The answer disappoints, and the easy conclusion is that the model isn’t very good. It usually is. The prompt didn’t say enough for any answer to be the right one.

“Summarise this” never told the model who the summary is for, how long it should be, or what you care about. “Write me an email” never said what about, in what tone, with what outcome. A person handed the same instruction would ask follow-up questions. The model doesn’t always ask; it guesses, and an average guess is what you got.

This is the Description skill from the AI fluency framework: saying clearly what you want so the model can act on it (more on the wider framework in the 4D framework for working with AI). The other half is Discernment: judging whether the answer it gave back is right before you use it. Most everyday frustration with AI lives in the gap between those two. This is a field guide to closing it: what a workable prompt is made of, the handful of mistakes that produce most bad answers, and how to repair a response without starting from scratch.

Anatomy

What a prompt that works is made of

A prompt the model can act on has four parts. Not every prompt needs all four, but when an answer disappoints, the missing piece is almost always one of these.

Diagram: the four parts of a workable prompt, stacked as labelled blocks: role and context (gray), the task (blue), constraints and format (teal), and an example (coral). Together they form a prompt the model can actually act on. ROLE / CONTEXT who the model is, who it's for, and why you're asking THE TASK exactly what you want done, stated plainly and directly CONSTRAINTS & FORMAT the shape and limits: a table, 3 bullets, 200 words, plain tone EXAMPLE one or two samples of the output you actually want a prompt the model can actually act on
The four parts of a workable prompt. Role and context tell the model where it stands; the task says what to do; constraints and format set the shape; an example shows the target. Most weak prompts are missing two of the four.

Take the weak prompt and rebuild it. “Summarise this” becomes: “You’re helping me prep for a budget meeting (role and context). Summarise the attached report (the task) as five bullets, each under fifteen words, focused only on cost changes and risks (constraints and format). Here’s the style I want: ‘Cloud spend up 18%, driven by the new logging pipeline’ (example).” The model now has somewhere to stand. The summary comes back about the thing you actually care about, in the shape you can paste straight into your notes.

The same rebuild works on the email. Give it the context (broken heater, two prior emails, you want a repair date), the task (a firm but polite follow-up), the format (short, three sentences), and a line of the tone you want. The point isn’t longer prompts for their own sake. It’s that each part removes one thing the model would otherwise have to guess.

The usual mistakes

Seven ways prompts go wrong

Across Anthropic’s prompt engineering overview and its interactive tutorial, the same techniques keep appearing as the highest-impact ones: be clear, give context, show examples, let the model reason, name the format, give a role. The common mistakes are just those techniques missing. Here are the seven that produce most bad answers, each with its one-line fix.

  • Vague instruction. “Make it better,” but better how? Fix: say exactly what you want, the way you’d brief a new colleague with no background.
  • Missing context. The model can’t know your audience, your constraints, or why you’re asking. Fix: state the why, the who, and the limits up front.
  • No example. You describe the output instead of showing it. Fix: paste one or two samples of the shape you want.
  • No format named. You leave the shape to chance and get a wall of prose. Fix: name it, whether a table, three bullets, or a 200-word summary.
  • Too many things at once. One prompt asks for a summary, a translation, and a plan, and each comes out thin. Fix: do one job per prompt, or number the asks.
  • A reasoning question with no room to reason. You ask for a judgement but want it instantly. Fix: ask the model to think through the steps before giving the answer, chain-of-thought, which Anthropic recommends for anything analytical.
  • Assuming it remembers. You refer to “the document from earlier” it never actually saw, or that scrolled out of context. Fix: re-paste the thing you’re referring to instead of pointing at it.

The seventh mistake isn’t in the prompt at all: trusting the first answer without checking it. That’s the Discernment side of the AI fluency framework: the answer can read fluent and confident and still be wrong, and a polished surface is not evidence.

Fixing the answer, not starting over

When the response is wrong, read the symptom

When an answer comes back wrong, the instinct is to rewrite the whole prompt and try again. Usually you don’t need to. The shape of the failure tells you which part of your prompt was thin: read the symptom, trace it to the cause, change one thing.

Diagram: a three-column flow reading symptom in the answer, then likely cause in your prompt, then the fix. Too generic comes from no context or example and is fixed by adding one example; made facts up comes from asking beyond what the model knows and is fixed by giving a source and allowing "I don't know"; wrong shape comes from naming no format and is fixed by specifying the format. SYMPTOM IN THE ANSWER LIKELY CAUSE THE FIX Too generic no context or example given add one example Made facts up asked beyond what the model knows give a source, allow “I don't know” Wrong shape no format named specify the format read the answer back to its cause in your prompt, then change one thing
Debugging an answer by its symptom. The way an answer is wrong points back to what your prompt left out. Fix the one missing part rather than rewriting everything.
Symptom in the answerLikely cause in your promptThe fix
Too generic, could be about anythingNo context or example givenAdd context and one example of the output you want
Made something up (a fact, a quote, a citation)Asked beyond what the model reliably knowsGive it the source to work from; tell it to say “I don’t know” rather than guess
Wrong format: prose when you wanted a tableNo format namedSpecify the shape: a table with these columns, three bullets, JSON
Far too long or too shortNo length setSet a concrete limit: “in 200 words”, “exactly five bullets”
Ignored part of what you askedToo many asks crammed into one sentenceNumber the asks, or split them into separate prompts
Right facts, wrong toneNo role or voice setGive it a role: “you’re a careful copy editor”, “write it warmly”
Refused or hedged when it shouldn’t haveA constraint read as off-limits, or the ask was ambiguousRephrase the constraint and say why you’re asking and what it’s for

The made-something-up row is worth sitting with, because it’s the one that quietly costs people. A model fills gaps with plausible text, so a question it can’t answer from what it knows produces a confident invention rather than a blank. Giving it the source to quote from, and explicitly permitting “I don’t know,” turns a guess back into an honest gap.

Don’t restart, iterate

Steering in follow-ups

You almost never need a fresh prompt. The chat already has the context, the draft, and your earlier instructions. Correcting in place is faster and keeps all of that. When an answer is 80% there, say what to change: “Good, but tighten it to three bullets and keep the second point exactly as is.” Or: “Same email, but drop the apology in the first line and make the deadline firmer.” You’re steering a draft, not commissioning a new one.

This is the Description and Discernment loop running live: you judge the answer (Discernment), you describe the adjustment (Description), the answer improves, you judge again. A few short turns usually beat one long prompt, because you’re reacting to a real output instead of trying to predict every requirement in advance.

A short checklist

Before you hit enter

A quick pass before you send, and a habit for after. Most of the seven mistakes get caught here.

  • Is the ask clear? Would a new colleague know exactly what to do from this sentence alone?
  • Did I give context? Who it’s for, why, and any constraints the model can’t know.
  • Is there an example? For anything where format or style matters, show one.
  • Did I name the format and length? The shape (table, bullets, prose) and the size.
  • One job or many? If it’s many, number them or split them.
  • Will I actually check the answer? Decide before you read it that you’ll verify the facts, not just the fluency.

That last item is the Discernment habit, and it matters most when you’ll act on the output. The case for checking what you ship, rather than trusting a confident-looking result, is the whole argument of vibe coding versus engineering: the output looking right is not the same as it being right. And if you want to get better at this steadily rather than picking it up by osmosis, becoming AI-fluent: a learner’s playbook is the longer path. Anthropic’s own foundations course frames the same two skills as the base everything else builds on.

Good prompting isn’t a trick or a secret phrase. It’s the ordinary discipline of saying what you want clearly, showing an example when shape matters, and reading the answer back critically, then adjusting in place instead of starting over. Do that, and most of the answers that used to disappoint stop disappointing.

Cited sources