Instruction Clarity and Specificity
The single most reliable lever for improving prompt output quality is specificity — and yet vagueness is the default failure mode of almost every person who starts working with language models. This module dissects why vague instructions produce vague outputs, gives you concrete techniques for achieving specificity, and shows you how to decompose complex tasks into the atomic instructions that models handle best.
Vagueness Is a Probability Problem
When you issue a vague instruction, you are not giving the model latitude to be creative — you are expanding the probability distribution over possible outputs to include everything from brilliant to useless. The model picks a point from that distribution, and without constraints, it tends to pick the mode: the most common, most generic, most average response that has ever followed similar text.
Consider the instruction: "Help me write an email." The model now must guess: who is the recipient? What is the relationship? What is the subject? What tone is appropriate? How long should it be? What action should it prompt? What is the cultural context? Each of these dimensions multiplies the space of possible appropriate responses. The model cannot optimize for your actual need because it does not know what that need is. It produces the average email — often inoffensive, often unhelpful.
Specificity works by collapsing this probability space. Each constraint you add eliminates an entire class of possible wrong outputs. "Write a 150-word follow-up email to a potential client who attended our product demo on Tuesday, expressing appreciation for their time, summarizing the two key points they seemed most interested in (real-time analytics and the API integration), and proposing a 30-minute call next week" leaves the model almost no room to produce something you did not want.
The Five Dimensions of Instruction Specificity
Becoming specific is not just about adding more words — it is about systematically addressing the dimensions along which a task can be underspecified. For most instructions, those dimensions are:
The Goal Description vs. Process Description Distinction
One of the subtlest and most important distinctions in prompt engineering is between describing what you want the output to achieve versus describing the process by which the model should produce it. Both are valid, but they serve different purposes and have different failure modes.
Goal description tells the model what the output should accomplish: "Write a product description that makes a skeptical reader want to try the product, not just understand what it does." This is powerful because it invokes the model's judgment about what approaches achieve that goal. The model can use narrative, social proof, specific claims — whatever it determines is most persuasive.
Process description tells the model how to produce the output: "First, identify the main objection a skeptical reader would have. Then, address that objection directly in the opening sentence. Follow with a specific use case example. Close with a concrete benefit statement." This is powerful when you know exactly what process produces good results and want consistency across many runs.
Use goal description when you want the model to apply judgment and creativity within a defined outcome. Use process description when you need consistency, when you know the exact steps that produce good results, or when the model's default approach to achieving the goal is not what you want.
The most sophisticated prompts often combine both: describe the goal, then constrain the process to ensure the model reaches it in a way that is appropriate for your context.
Decomposing Complex Tasks
A critical specificity technique is task decomposition — breaking a complex instruction into its component steps. Models handle atomic tasks much better than compound ones. When you ask a model to "analyze this business proposal and tell me if I should invest," you are asking it to simultaneously understand the business, assess market size, evaluate the team, model financial projections, assess your risk tolerance, and make a recommendation. It will do all of these poorly because each deserves focused attention.
Decomposed version:
Each step is a task the model can execute well. The compound instruction produces a mediocre, generic assessment. The decomposed version produces specific, actionable analysis. The output from step 3 alone is often worth more than the entire response from the compound version.
When decomposing, watch for hidden steps. "Write a cover letter" actually involves: (1) understanding the job requirements, (2) identifying the applicant's most relevant experience, (3) matching experience to requirements, (4) drafting opening that creates immediate relevance, (5) structuring the body, (6) writing a closing call to action, (7) calibrating tone to the industry. Making these steps explicit — even in a single prompt — dramatically improves output quality.
Using Inline Examples
One of the most efficient specificity techniques is the inline example: providing a small concrete example of what you want, directly in your instruction. Examples communicate requirements that are hard to specify in abstract terms. They show the model the exact style, level, and format you need.
"Write a concise, professional bio for our website."
The model has to infer what "concise" means to you (it could range from 50 to 300 words), what tone "professional" implies in your industry, and what structure a bio should take on your specific type of site.
"Write a concise professional bio for our website. Here is an example of the style and length we're going for: 'Sarah Chen is a product designer who has shipped mobile experiences used by over 40 million people. Previously at Stripe and Figma, she now leads design at Acme Corp.' Use this as a structural model — third person, 2-3 sentences, specific credential, current role — but write fresh content for the person described below."
The example does more specification work in one sentence than a paragraph of abstract description could achieve.
Common Clarity Failures and Their Fixes
Experienced prompt engineers have catalogued the most common clarity failures. Recognizing these patterns in your own prompts is the first step to eliminating them.
The Hedged Request. "Could you maybe help me think through some ideas about X?" This signals uncertainty about what you want, and the model responds with equal uncertainty — vague, exploratory, noncommittal. Fix: state what you want directly. "Generate 10 specific ideas for X, each with a one-sentence rationale."
The Compound Task. "Write a blog post about X, make sure it's SEO-optimized, include statistics, and keep it engaging." These four requirements interact in complex ways and different models will weight them differently. Fix: specify the hierarchy. "Write an engaging 800-word blog post about X. Prioritize readability. Include 2-3 specific statistics (which I will verify). Do not sacrifice clarity for keyword density."
The Missing Negative. Specifying what you want but not what you want to avoid. "Summarize this article" may produce something that includes opinions, quotes long passages, or uses the passive voice throughout. Fix: add explicit exclusions. "Summarize this article in 150 words. Do not include direct quotes. Do not include the author's opinion — only factual claims. Write in active voice."
The Ambiguous Pronoun. Long prompts often introduce pronouns whose antecedents are unclear. "Take the first document and apply its structure to the second document, then revise it to match the third." What does "it" refer to? Fix: use explicit nouns. "Take Document A's structure and apply it to Document B's content. Then revise the resulting hybrid to match Document C's tone."
Before submitting any important prompt, read it as if you were the model — a system that has no access to your intentions, your history, or your unstated assumptions. Ask: what would a literal reader do with this instruction? If the answer is "many different things," add more specificity until the answer is "exactly what I need."
Calibrating Specificity to the Task
More specificity is not always better. Over-specification can constrain the model so tightly that it cannot produce quality output. If you specify every sentence structure, every argument, and every word choice, you might as well write the content yourself. Effective specificity means specifying everything the model needs to eliminate wrong outputs, while leaving the model enough room to apply its genuine capability in the areas where its judgment is valuable.
A useful heuristic: specify outcomes and constraints, leave methods and phrasing open. "Write a compelling argument for X, no longer than 200 words, using no jargon, suitable for a general audience" gives the model exactly what it needs to produce something useful. "Start with a rhetorical question, follow with three supporting points each exactly two sentences long, and close with an imperative" is over-specified and will produce something mechanical.
The right level of specificity is the minimum level needed to ensure the output lands in the right space. Getting there requires iteration — and building intuition about which dimensions of under-specification actually matter for a given task type.