The Anatomy of a Good Prompt

Most weak prompts are not wrong, they are vague. They give the model one signal when they could give it four. This post breaks a prompt into its parts so you can see what is missing, then covers the design habits that make those parts land. It is part three of Prompt Engineering, Properly; the previous part covered the settings around the prompt, and this one is about the structure inside it.

The four parts#

A prompt can contain up to four elements. You rarely need all four, and the format depends on the task, but knowing them gives you a checklist for what to add when an output is off.

Instruction. The specific thing you want done: "Summarize", "Classify", "Translate", "Extract". This is the one part you almost always have.

Context. External information that steers the model: background, constraints, examples, who the output is for. This is the part most people leave out, and it is usually what is missing when the model technically follows the instruction but misses the point.

Input data. The actual thing to act on: the ticket text, the review, the email. The content, as opposed to the instruction about the content.

Output indicator. The type or format you want back: a label, JSON, a number, a particular layout. It tells the model where its answer goes and what shape it should take.

Here is the canonical small example, a classification prompt, with the parts labeled:

Classify the text into neutral, negative, or positive   <- instruction
 
Text: I think the food was okay.                          <- input data
 
Sentiment:                                                <- output indicator

There is no context here, and for a task this simple it does not need any. But context is exactly where you would add examples or rules if the model started mislabeling edge cases. The four parts are a diagnostic: when output is wrong, ask which element is weak or missing, and add that one.

The habits that make the parts work#

Knowing the parts is not enough. How you write them decides whether they help. A few habits, drawn straight from how the model behaves.

Start simple, then add#

Prompting is iterative, not something you get right in one shot. Begin with a plain version, run it on real inputs, and add elements as you find gaps. If a task is big, break it into smaller subtasks rather than cramming everything into one giant prompt. Adding complexity upfront just gives you more places to be wrong. (Breaking a task into linked steps is its own technique, prompt chaining, coming later in this series.)

Be specific, but only with relevant detail#

The more precisely you describe the task and the desired output, the better the result. Specificity is the habit with the most payoff. But there is a trap on the other side: piling on detail that does not serve the task just adds noise and eats context. The detail has to earn its place.

A clean example of specificity doing real work, pulling place names out of text by stating the exact output format:

Extract the name of places in the following text.
 
Desired format:
Place: <comma_separated_list_of_places>
 
Input: "... says Henrique Veiga-Fernandes, a neuroimmunologist at the
Champalimaud Centre for the Unknown in Lisbon. ..."

Place: Champalimaud Centre for the Unknown, Lisbon

The "Desired format" line is the output indicator doing its job. Without it you would get a sentence; with it you get something you can parse.

Avoid being clever and imprecise#

It is easy to overcorrect from "be specific" into writing something fussy and vague at the same time. Direct beats clever. Compare:

Before:

Explain the concept of prompt engineering. Keep the explanation short,
only a few sentences, and don't be too descriptive.

After:

Use 2-3 sentences to explain the concept of prompt engineering to a
high school student.

The after version gives a concrete length and a concrete audience. "A few sentences" and "not too descriptive" are vibes the model has to guess at. "2-3 sentences" and "to a high school student" are targets it can actually hit. The analogy is plain human communication: the more direct the message, the more reliably it lands.

Say what to do, not what to avoid#

Models follow positive instructions more reliably than negative ones. Listing what not to do keeps the forbidden thing salient and often backfires. The guide has a sharp example: a movie-recommendation agent told DO NOT ASK FOR INTERESTS. DO NOT ASK FOR PERSONAL INFORMATION. immediately asks the customer what kind of movie they like. The fix is to describe the behavior you want instead:

The agent recommends a movie from the top global trending movies. It
refrains from asking about preferences or personal information. If it
has no movie to recommend, it says: "Sorry, couldn't find a movie to
recommend today."

Now the model has a positive thing to do (recommend from trending) and a defined fallback, so it stops trying to interrogate the user. I made the same point with a length example in the series intro; it holds across tasks.

Putting it together#

Here is a weak prompt and a rebuilt one, with the four parts and the habits applied.

Before:

Summarize this feedback.

After:

### Instruction ###
You are triaging product feedback for the engineering team. Summarize
the feedback below.
 
### Context ###
The team only acts on bugs and feature requests, not general praise.
 
### Output ###
Return JSON: {"type": "bug" | "feature_request" | "other",
"summary": string (one sentence), "severity": "low" | "med" | "high"}
 
### Feedback ###
"""
{feedback_text}
"""

Every part is present and pulling its weight: instruction (summarize, with a role), context (what the team cares about), output indicator (the JSON shape), and input data (separated and quoted). You will get back something consistent and parseable instead of a paragraph that varies every run. If the output format matters this much, the next step up is enforcing it with structured outputs rather than asking in prose, which I cover in Structured outputs and function calling.

Wrapping up#

When a prompt underperforms, do not rewrite it from scratch. Run the checklist: is the instruction specific, is there context the model needs, is the input clearly separated, is the output shape stated. Add the missing part, change one thing, and test. That is the whole method.

Next in the series: Zero-shot vs few-shot prompting, where we go deep on the single most effective kind of context you can add, worked examples. The previous part is The settings that change your output.