Claude does its best work when you remove the guesswork. A vague prompt forces it to fill gaps with assumptions, and those assumptions are often wrong. Specific prompts get specific results.
Compare these two requests:
Fix the login bug.
Users with expired sessions see a blank page instead of being sent to /login.
The redirect logic lives in middleware.js. It should send them to /login
and keep the original URL as a `next` query param. Do not change the API routes.
The second one names the file, describes the exact symptom, states the expected behaviour, and draws a boundary around what not to touch. Claude can act on that immediately.
A few habits that sharpen almost any prompt:
- Name the target. Point at the file or function instead of describing it. Use
@file mentions so Claude reads the real thing. - State constraints up front. "Do not change the public API" or "keep it under 50 lines" saves a round trip.
- Describe done. Say what the finished result should do, not just what is broken.
- Give one task at a time when the work is tricky, so you can check each step.
Specificity is not about writing a wall of text. It is about front-loading the details Claude would otherwise have to ask for or invent. A three-line prompt with the right three facts beats a rambling paragraph.
If you are not sure what details matter, ask Claude to restate the task back to you before it starts, or use plan mode so it proposes an approach first. Catching a wrong assumption in a plan is far cheaper than catching it in a pile of finished code.
Comments
Be the first to comment.