Being specific

Your prompt is now clear and direct. It scored 3.92 — better than the baseline but still not a prompt you'd ship. The next technique is the one that more than doubles the score in a single iteration: being specific. Specifically, adding explicit output quality guidelines and, when the task warrants it, explicit process steps.

The vagueness problem

Here's the situation. You say:

Write a short story about a character who discovers a hidden talent.

Claude can take this in fifty different directions. The story could be 200 words or 2,000. It could have one character or five. The "hidden talent" could be anything from singing to telekinesis. Any output Claude produces is defensible against the prompt as written, because the prompt didn't specify what a good answer looks like.

The fix is specificity: telling Claude the shape of the answer, not just the topic. There are two flavours.

Output quality guidelines

Output quality guidelines are an explicit list of properties the output should have. Think of them as acceptance criteria for the generated response. They control:

• Length — "Keep the response under 500 words" or "Provide at least three paragraphs."
• Format and structure — "Return valid JSON" or "Use a numbered list."
• Required elements — "Include a code example for each technique."
• Tone and style — "Write in a matter-of-fact voice" or "Avoid marketing language."

For the short-story example, guidelines might look like:

• The story must be under 1,000 words
• It must include a clear scene where the talent is first revealed
• It must feature at least one supporting character

Now Claude knows what "done" means. It still has creative latitude — the content is entirely its call — but the shape is pinned down.

Use output guidelines on almost every prompt. They are your safety net for consistency. A prompt without guidelines is a prompt that will drift in unpredictable ways across different inputs.

Process steps

Process steps tell Claude how to think about the problem before answering. Instead of letting it jump straight to output, you walk it through a small chain of reasoning.

For the story example:

1. Brainstorm three talents that could create dramatic tension in a realistic setting
2. Pick the most interesting of the three
3. Outline a pivotal scene where the talent is revealed
4. Brainstorm supporting character types that could amplify the impact
5. Write the story

This turns a one-step request into a five-step reasoning flow. The output quality goes up because Claude is explicitly considering alternatives before committing — the same way a human writer would.

Use process steps for complex problems — troubleshooting, analysis, decision-making, anything where you want the model to consider multiple angles before settling on an answer. Asking Claude to analyse "why did our sales team's performance drop" without steps gets you a single-cause explanation; asking it to first examine market conditions, then individual performance, then org changes, then customer feedback, gets you an analysis that actually resembles thorough root cause work.

Combining both

In production prompts, you'll often use both at once. Guidelines control what the output looks like; steps control how Claude arrives at it. The pattern is:

[Clear and direct opening instruction]

Follow these steps:
1. ...
2. ...
3. ...

Guidelines:
- ...
- ...
- ...

Apply it to the meal plan prompt

Here's the previous version:

Generate a one-day meal plan for an athlete that meets their dietary restrictions.

Good opening. Now add guidelines. The grader's extra_criteria already told us what the prompt needs to produce — caloric total, macro breakdown, meal timing. Bake those into the prompt as explicit requirements:

Generate a one-day meal plan for an athlete that meets their dietary restrictions.

Guidelines:
1. Include the accurate daily calorie amount for the athlete's stats and goal
2. Show protein, fat, and carbohydrate amounts per meal and for the day
3. Specify the time at which each meal should be eaten
4. Use only foods that fit the stated dietary restrictions
5. List all portion sizes in grams
6. Keep meals budget-friendly if budget is mentioned

Six guidelines. Each one is a concrete, checkable property of the output. Guideline 1 forces accurate calorie calculation. Guideline 2 forces macro reporting. Guideline 3 forces meal timing. Guideline 4 forces restriction compliance. Guideline 5 forces precise quantities. Guideline 6 covers an edge case.

Notice that the guidelines mirror — and extend — the extra_criteria we gave the grader. That's on purpose. The prompt should tell Claude to do exactly the things the grader is checking for. If there's a gap between what the grader wants and what the prompt asks for, you're asking the grader to give points for things you didn't even request.

The score jumps from 3.92 to 7.86

Run it. Same dataset, same grader, same extra_criteria. The score goes from 3.92 to 7.86 — more than double. You didn't change the opening line, you didn't add examples, you didn't restructure the prompt. You just told Claude explicitly what the output should contain.

This is the single biggest lift any one technique will produce in this module. Guidelines are cheap to write and enormously effective, because they take the failure modes the grader is already telling you about and promote them to hard requirements in the prompt.

Why this works

Language models default to middle-of-the-road output when the prompt is ambiguous. Specificity collapses ambiguity. Every guideline you write is a degree of freedom you take away from the model — and in most production use cases, reducing freedom is exactly what you want. You're not paying Claude to decide what format the meal plan should be in. You're paying it to fill in the fields of a format you already know you want.

Make specificity the technique you reach for second, right after clear and direct. And make the guideline list the thing you grow first when an eval tells you the prompt is missing something.