Anatomy of a good prompt

Most people write prompts the way they send a text message: quick, compressed, context-free. That works fine for simple requests, but as tasks grow more specific, the gap between what you mean and what the model produces grows wider. Understanding the internal structure of a prompt gives you a reliable way to close that gap without guessing.

The four components

An effective prompt has up to four distinct parts. You don't always need all four — but knowing each one lets you add exactly what's missing when output drifts off target.

Task — what you want done. The verb at the heart of the request: summarise, rewrite, generate, explain, classify, translate, debug. This is the only truly mandatory component. Every prompt has one, even if it's buried or implied.

Context — background the model can't infer. Who the audience is, what the codebase looks like, what constraints exist in your environment, what the document is for. Context narrows the enormous space of possible correct answers down to the one that's actually useful to you.

Format — how the output should be shaped. Bullet list or prose? Markdown or plain text? A diff or a whole file? Short paragraph or detailed breakdown? When you don't specify, the model picks whatever it last saw work. That's often fine — and sometimes wrong.

Constraints — what to avoid or limit. "Don't use external libraries." "Keep it under 200 words." "Avoid jargon." Constraints are the negative space of the task: things that would technically satisfy the task description but that you don't want.

Seeing the difference

Here is the same request, written two ways.

Without structure:

Explain this function.

The model will produce something — probably a generic line-by-line walkthrough at an assumed skill level. It might be too basic or too advanced. It might produce prose when you wanted a comment block. It might cover what the code does without explaining why.

With structure:

Task: Explain what this Python function does. Context: The reader is a junior developer who understands loops and conditionals but hasn't used recursion yet. Format: Two paragraphs: one describing what the function does at a high level, one walking through a concrete example. Constraints: Don't use technical vocabulary beyond what a beginner would know; don't include code in the explanation.

The second prompt is longer. But the extra words are load-bearing — each one removes a degree of freedom the model would otherwise resolve arbitrarily. The output arrives closer to usable on the first try.

When simple is right

The framework exists to fix problems, not to pad every request. For a task like "what is the capital of France?" no context, format, or constraints are needed — the task is unambiguous. Forcing structure onto simple requests makes them worse, not better: more text for the model to parse and more chance of accidentally constraining an answer you wanted to be open.

The useful heuristic: if a prompt produces a poor result, ask which component is missing or wrong before adding more words. Usually one is the culprit — a missing audience specification, an unspecified output format, or a constraint you forgot to include.

Diagnosing a bad output

When output misses the mark, map the failure to its missing component:

• Output is too generic or doesn't fit your situation → missing Context
• Output is the wrong shape (prose when you needed a list, too long, wrong language) → missing Format
• Output technically satisfies the request but includes something you didn't want → missing Constraints
• Output is off-topic or does the wrong thing entirely → the Task itself was ambiguous

This diagnostic reflex turns "it gave me a bad response" into a specific, fixable problem.

Where to go next

You now have a structural vocabulary for what goes into a prompt. The next lesson looks at one of the most reliable levers for shaping output: role and persona prompting — how assigning a role to the model changes the register, depth, and focus of its responses.