Prompting is not mystical. It's the skill of accurately representing your situation, your intent, and your standards to a system that knows nothing about any of them by default. Here's what that looks like in practice.
The fastest way to understand good context is to see the same request with and without it.
── WEAK PROMPT ──────────────────────────────────────────── Write me an email about the server outage. ── STRONG PROMPT ────────────────────────────────────────── I'm a senior infrastructure engineer writing to our VP of Engineering and CTO. We had a 47-minute outage this morning (6:14–7:01 AM EST) affecting our primary API gateway, which impacted roughly 2,300 customers. Root cause was a failed config push that bypassed our staging validation step. We have a postmortem scheduled for Thursday. Write a concise incident communication — 3 short paragraphs: what happened, impact, and what we're doing to prevent recurrence. Tone should be direct and factual, not defensive. No jargon. Assume the reader is technical but focused on business impact, not implementation details.
The weak prompt will produce a generic incident email template. The strong prompt will produce something you could send. The task is the same. The context is everything.
Two kinds of role context matter:
Your role: Who are you? What's your background? What can the model assume you already know? "I'm a network engineer" unlocks a completely different vocabulary and assumed baseline than "I'm a small business owner trying to understand my IT setup."
The model's role: Who do you want it to be? "Act as a skeptical peer reviewer" produces fundamentally different output than "Act as a patient teacher." You're not changing what the model knows — you're steering which statistical neighborhood it operates in. "Senior security engineer reviewing this architecture for vulnerabilities" activates different patterns than "helpful assistant explaining this architecture."
When you tell the model to be a "skeptical peer reviewer," you're not programming a personality. You're priming the probability distribution with patterns from the vast amount of skeptical peer review language in training data — academic critique, code review comments, adversarial analysis. That language pattern shapes every token that follows.
"Explain X" is a topic. "Give me a three-paragraph explanation of X suitable for a weekly team newsletter, written at a level appropriate for software engineers who don't work in AI" is an output specification. The difference is what you get back.
Output specifications to consider:
The single most underused prompting technique is providing examples of what you want. Not a description of what you want — an actual sample.
If you want the model to write in a particular voice, paste two paragraphs written in that voice and say "write more in this style." If you want a specific output format, show it one completed example and say "produce five more like this." If you want a specific level of technical depth, show it something at that depth and say "match this level."
Examples work because they shift the probability distribution directly — the model is now generating the statistically likely continuation of the pattern you've shown it, rather than sampling from its generic understanding of your description. Seeing is more powerful than being told.
This technique has a formal name: few-shot prompting. You provide a few examples (the "shots") of input-output pairs before your actual request. Even one or two examples dramatically improve consistency and format compliance. Zero examples (just a description) is called zero-shot — and it's noticeably less reliable for format-sensitive tasks.
Negative constraints are as valuable as positive instructions. "Don't use bullet points" is a context signal. "Don't suggest starting over — I need to fix the existing approach" is a context signal. "Don't explain what X is — I already know, just address the specific problem" is a context signal.
Without negative constraints, the model defaults to its most common behavior for the task type. Common behaviors are common because they're usually appropriate — but "usually appropriate" and "what you specifically need" are different things.
Even the most experienced prompt writers iterate. The first output is rarely the final one — not because the model is bad, but because writing a prompt forces you to articulate what you actually want, and sometimes you don't fully know until you see something that's close but not quite right.
The key discipline is: when a response misses the mark, diagnose why before revising. What context was missing? What was ambiguous? What assumption did the model make that you didn't intend? Adding that specific correction to the next prompt is more effective than starting over or just saying "try again."
"That's good, but make it less formal and cut the third paragraph — that's not relevant to my situation because X" is a perfect iteration. "That's wrong, try again" is not — it gives the model nothing new to work with, so it samples the same distribution and produces something similar.
Every revision is adding context. Each correction tells the model more specifically what the target is. A good multi-turn prompting session is a process of progressively narrowing the probability distribution until it's centered exactly on what you need. The model isn't getting smarter — the context is getting richer.
Three words. No role, no format, no constraints, no examples. The model will produce the statistical average for that query type. Occasionally that's exactly right. Usually it isn't.
"Make this better" — better how? More concise? More detailed? More formal? More accurate? The model will pick one. It may not pick yours.
Critical constraints hidden in the middle of a long prompt are often underweighted. The beginning and end of a prompt have disproportionate influence. Important constraints belong at the top, restated if necessary at the bottom.
Changing requirements mid-conversation without acknowledging the change. The full conversation history is in context, including your earlier (now contradicted) instructions. Explicitly state when you're changing direction: "Actually, disregard the formal tone I asked for — I need this to be casual."
Take a task you do regularly — writing a status update, drafting an email, summarizing a document, troubleshooting a problem — and write out the fullest possible prompt for it: role, task, format, constraints, examples. What would you include that you've never included before? What would the result look like compared to what you normally get?