Be Clear, Direct, and Specific

The mental model: a brilliant new hire with zero context

The single most useful way to think about prompting: Claude is a very capable new employee who started today. It knows how to program, write, and reason — but it knows nothing about your project's norms, your audience, or what "done" means to you. The more precisely you explain those things, the better the result. Vague prompts don't fail because the model is weak; they fail because you left the important decisions unstated and the model had to guess.

This leads to Anthropic's golden rule of clear prompting: show your prompt to a colleague with minimal context on the task. If they'd be confused, Claude will be too. It's a cheap test you can run in your head before every prompt.

What "specific" actually means

Three things turn a vague request into a specific one:

1. Success criteria — what does a correct result look like? How will you check it?
2. Audience and purpose — who reads this output, and what will they do with it?
3. Format — structure, length, headings, code vs prose, JSON vs table.

Compare a real example:

The specific version names the symptom, points at the likely location, and defines the verification standard (a failing test first). The vague version forces Claude to guess all three — and any wrong guess wastes a round trip.

Numbered steps when order matters

When a task has an order or a completeness requirement, write it as a numbered list. Claude follows sequential steps far more reliably than steps buried in a paragraph:

1. Read the three CSV files in data/ and report their row counts.
2. Merge them on the "user_id" column.
3. Drop rows with a null "signup_date".
4. Write the result to data/merged.csv and print the final row count.

Each step is checkable. If step 3 gets skipped, you can see it immediately.

Explain the why, not just the what

Adding the motivation behind an instruction makes Claude generalize correctly instead of following the letter of a rule. Example: "Never use ellipses" is a bare rule. "Your response will be read aloud by text-to-speech, so never use ellipses — the TTS engine can't pronounce them" tells Claude the real constraint, so it will also avoid other things a TTS engine mangles, without you listing them all.

Say what TO do, not what to avoid

Negative instructions ("don't use markdown") make the forbidden thing more salient and leave the desired behavior undefined. Positive instructions define the target directly: "write your response in flowing prose paragraphs." Whenever you catch yourself writing "don't...", try rewriting it as the behavior you actually want.

Ask for "above and beyond" explicitly

Claude aims for exactly what you asked. If you want ambition — extra features, polish, edge-case handling — say so, because it won't be inferred:

Include as many relevant features and interactions as possible.
Go beyond the basics to create a fully-featured implementation.

The reverse also holds: if you want the minimal change, say that. Silence gets you the model's default guess about scope, which may match neither.

A worked rewrite

Weak prompt:

Summarize this customer feedback.

Strong prompt:

You're preparing input for our quarterly product planning meeting.

Summarize the customer feedback below for the product team:
1. Group complaints into at most 5 themes, most frequent first.
2. For each theme, give a count and one representative quote.
3. Flag anything mentioning data loss or security as CRITICAL at the top.

Format: markdown with one ## heading per theme. Keep it under 400 words —
it will be skimmed in a meeting, not read closely.

Every sentence in the strong version removes a guess: the audience (product team, skimming), the structure (themes, counts, quotes), the priorities (security first), and the size (under 400 words). None of this is advanced technique — it's just refusing to leave decisions implicit.

The pre-flight checklist

Before sending a prompt that matters, check:

• Would a colleague with no context know exactly what I want? (Golden rule.)
• Did I state the output format and rough length?
• Did I say who the output is for and what they'll do with it?
• If order matters, are the steps numbered?
• Did I explain why for any unusual constraint?
• Are my instructions phrased as what to do, not what to avoid?
• If I want extra effort or strictly minimal scope, did I say so?

Clarity is the highest-leverage prompting skill because every other technique builds on it. A structured, example-rich prompt built on a vague core request still produces a confident answer to the wrong question.