If there’s one skill that separates developers who get real value from Claude and developers who bounce off it after a week, it’s this one. Everything else in this series assumes you can prompt well — so it’s worth slowing down here.
The instinct to unlearn
Most new users prompt like they’re searching Google: short, vague, and hoping the tool fills in the gaps. Claude will try — and it’ll often guess wrong, not because it’s incapable, but because you gave it a genuinely ambiguous instruction. The fix isn’t a magic phrase. It’s treating the prompt like a message to a capable colleague who wasn’t in the meeting where you decided what you wanted.
Weak vs. strong, side by side
| Weak | Strong |
|---|---|
| “Make the signup form better” | “The signup form doesn’t validate email format client-side, so users only find out after submitting. Add inline validation with an error message under the field.” |
| “Add tests” | “Add unit tests for the calculateDiscount function in src/pricing.js, covering the zero-quantity edge case and the case where the coupon is expired.” |
| “Fix the bug” | “Clicking ‘Save’ twice quickly creates two records instead of one — likely a missing debounce or a race condition in the submit handler.” |
Notice the strong versions all share three things: what’s wrong or wanted, where (when known), and why it matters. You don’t always know the “where” — that’s fine, Claude will find it — but include it whenever you do.
Context is not the same as length
A common overcorrection is writing paragraph-long prompts stuffed with irrelevant detail. That’s not better — it just makes the important part harder to find. Good context is relevant, not long:
- What outcome do you actually want?
- What constraints matter (performance, existing patterns, a library you must/mustn’t use)?
- What have you already tried, if anything?
Prompting is iterative — use that
You don’t need to get the perfect prompt on the first try. A real, productive exchange looks like:
You: “Add a rate limiter to the API.”
Claude: proposes an approach, asks which endpoints, what limit.
You: “Just the /login endpoint, 5 attempts per minute per IP.”
Claude: implements it, shows the diff.
That back-and-forth is not a failure of your first prompt — it’s the workflow working as intended. Treat the first message as an opening move, not a one-shot spec.
Correcting course without starting over
When Claude does something you didn’t want, the instinct to type “no, undo everything and start over” is usually wrong. Be specific about what’s off:
Better: “This works, but you put the validation logic in the controller — move it into the existing
validators/folder to match the rest of the codebase.”
Specific correction is faster than a restart almost every time, and it teaches you exactly where the miscommunication happened.
A short do/don’t list
- Do say what “done” looks like, when you know.
- Do mention constraints up front (a deadline, a library ban, a style guide).
- Don’t assume Claude remembers something from three sessions ago — each session’s context is its own.
- Don’t bury the actual ask in unrelated backstory.
Next: with good prompting in hand, it’s time to look at what Claude actually does when it acts — the tools behind editing, running commands, and multi-step autonomous work.