Be specific

The previous lesson was about fixing vague prompts after the fact, with follow-ups. This lesson is the prevention: writing prompts specific enough that you need fewer follow-ups.

Specificity isn’t pedantry. It’s how you communicate intent.

Tell a contractor “make the kitchen better” and you’ll get some kitchen. Maybe not yours. Same idea here.

Vague vs specific

A vague request:

Make the homepage look better.

What does Claude do? It guesses. It changes some colors, swaps some fonts, maybe adds a hero section. Some of it you like. Some of it you didn’t ask for. Now you’re in a follow-up loop.

The specific version:

On the homepage, make the H1 headline about 1.5× its current size. Reduce the navigation bar height to 48px. Leave the hero image and the footer alone.

Same overall goal. Wildly different precision. Claude makes those exact changes — no creative liberties — and you’re done in one round.

The four things that turn vague into specific

When a request feels too short, run through these:

1. What. What’s actually changing? (the H1 size)
2. Where. Which file, which page, which function? (on the homepage, in Header.tsx)
3. How. What’s the new value or behavior? (1.5× larger)
4. What not to touch. What should stay the same? (leave the hero image and the footer alone)

The fourth is the one people forget. Claude is helpful by default — it’ll often “improve” things you didn’t ask about. Pinning down what’s off-limits is how you keep that helpfulness in scope.

When vague is fine

Specificity is a tool, not a tax. Some prompts are fine fuzzy:

• “Explain this file.” — reading, not writing. You want Claude’s interpretation.
• “What’s the right way to handle errors here?” — you’re asking for a recommendation, not an edit.
• “Find me all the places we still use the old auth library.” — search task. There’s only one right answer.

Rule of thumb: the more Claude has to invent, the more specific you should be. A clear edit needs precision. An open-ended question doesn’t.

What’s next

Specific prompts work when you can put the change into words. Sometimes you can’t — sometimes the fastest way to communicate the problem isn’t to describe it, it’s to show it.