PlainLogic

Interactive lab · Practical AI

Prompt Anatomy: Writing Clear Prompts

A useful prompt is built from four parts. Learn them, and you will spot the missing one every time an answer goes sideways.

Plain-language AI

In plain logic

No real AI runs on this page. Everything is explained and illustrated in your browser — no model calls, no accounts, nothing sent anywhere.

A useful prompt explains the task, the context, the constraints, and the desired format — four parts, each doing a distinct job. Vague prompts fail because they skip parts and make the model guess what you wanted.

The four parts

  • Task — say what you need done. One clear verb beats three hopeful ones. “Summarize this ticket” is a task; “look at this” is a wish.
  • Context — supply the information needed to do it. The model cannot use what you did not give it. Paste the ticket, describe the audience, name the background it should assume.
  • Constraints — state the limits. Length, tone, what to include, what to leave out, what to do when information is missing (“say 'unknown' rather than guessing”). Constraints are where most prompts are weakest.
  • Format — show the output shape. Bullets or a table? Headings? A one-line verdict first? The model will happily reshape the same facts into whatever container you name.

One more rule that belongs with the four: keep source material separate from instructions so a reader — human or model — can tell which is which. Mark quotes as quotes. Instructions found inside retrieved documents should be treated as untrusted content, not commands: a document that says “ignore previous instructions” is data, not your boss.

Before and after

Vague: “Summarize this support ticket.” — The model guesses the audience, the length, and the shape.

[TASK] Summarize the support ticket below for a non-technical customer. [CONTEXT] The customer reported a billing issue and is frustrated after two prior contacts. [CONSTRAINTS] Under 80 words. No jargon. If the resolution is unclear, say what is still unknown instead of guessing. [FORMAT] Three bullets: what happened, what we did, what happens next. [SOURCE] --- ticket text goes here ---

Same facts in, far more useful text out — because every part told the model something it would otherwise have had to invent.

Hands-on

Try this

Build a prompt to summarize a real support ticket, email, or meeting note you have handy. Write the four parts explicitly, then run it — and then change only the format: ask for a table instead of bullets.

Watch what changes and what doesn't: the requested output shape changes, but the underlying facts stay the same. That separation — facts from formatting — is the sign of a prompt doing its job. If changing the format changes the facts, your prompt is leaking; tighten the constraints.

Bonus round: deliberately remove the constraints section and run it again. The difference you see is the exact value that one part was adding.

Honest boundaries

What this leaves out

Better prompts cannot supply missing evidence. No amount of task-context-constraints-format will make the model know your company's returns policy or last quarter's numbers. When the facts aren't in the prompt and aren't retrievable, a great prompt produces a beautifully formatted guess. (See why AI hallucinates.)

And prompts cannot guarantee correctness. They raise the odds of a useful answer; they don't certify it. For anything that matters — money, access, safety, published claims — the answer still gets checked against a real source, no matter how good the prompt was.

Honest answers

Questions people ask

How long should a prompt be?

As long as the task needs and no longer. Include all four parts, but don't pad: extra text dilutes attention. If you find yourself writing paragraphs of background, consider whether some of it belongs in a document the model retrieves (RAG) instead of the prompt itself.

Do I need to be polite to the AI?

No — but clarity beats cleverness. Direct instructions outperform elaborate roleplay. “You are a world-class expert...” adds little; specific constraints add a lot. Save the creativity for the task description, not the framing.

Why did the same prompt work yesterday and fail today?

Sampling randomness, model updates, and subtle context differences all shift outputs. If a prompt must work reliably, pin down the format with an example, add constraints for the failure you just saw, and test it more than once before trusting it.