Most disappointing prompts are not badly written. They are missing a part. Once you can name the parts, debugging a prompt stops being guesswork.
The five parts
Instruction — what you want done. The single most common failure is an instruction that names no goal: make this better, improve this, look at this. Better in which direction? Shorter and more detailed are both "better", and they pull against each other.
Context — what the model needs to know that it cannot infer. Who is this for? What has already been tried? What is the surrounding situation? A model has no access to your project, your team or your last conversation unless you put it in the prompt.
Role — the perspective to answer from. "You are reviewing this as a security engineer" genuinely changes which details get surfaced, because it changes what counts as important.
Format — the shape of the answer. Length, structure, headings, whether you want prose or a table. If you do not specify it, you get the model's default, which is usually longer and more hedged than you wanted.
Constraints — what to avoid or stay inside. Word limits, "do not invent sources", "only use the text I gave you", "stay under three bullet points".
Vague to specific, worked
Start with the kind of prompt most people write:
Summarise this article.
It will produce something. You have no control over how long, for whom, or what it keeps.
Now add the parts:
Summarise the article below for a colleague who has not read it and has two minutes. Keep the author's main claim and the evidence they give for it. Drop the examples. Four bullet points, one sentence each. Do not add anything that is not in the text.
Instruction (summarise, keep the claim and evidence), context (a colleague, two minutes), format (four bullets, one sentence), constraint (drop examples, add nothing).
The second prompt is longer. That is the trade: specificity costs words and buys repeatability.
Where the system prompt fits
Chat tools separate a system prompt — standing instructions that apply to every message — from the message you type. Role and durable constraints belong in the system prompt. The instruction and the specific context belong in the message.
This matters when you build anything reusable. Put what is always true in the system prompt once, rather than repeating it in every request and forgetting it in one.
What this does not fix
A well-formed prompt does not make a model know something it does not know, and does not stop it from stating a confident wrong answer. Structure buys you control over shape and direction. Verification is a separate job, and it is the subject of a later stage.