Prompting Claude Code: say only what it can't see, “be ambitious”, and let it interview you

"Fix the login bug" versus "users report login fails after the session expires; look at token refresh in src/auth/, write a test reproducing it, then fix it": two prompts for the same job, but the second usually saves a round of back-and-forth. Claude Code's best practices page sums up the principle: only tell Claude what it can't see for itself. Today's models read code very well, so what's missing is information that exists only in your head. This post collects practical prompting tips from that page.

Specific prompts: before and after

Three things belong in a bug-fix prompt: the file/area, the symptom, and what "fixed" looks like. If you prefer one of two reasonable approaches, say so up front, because Claude can't read that from the code.

Hand over what you have, don't re-describe it

• Files: type @ and a path to include the file's contents in your message (it also loads that folder's CLAUDE.md).
• Images: paste error screenshots or design mockups straight into the prompt.
• Command output: pipe it from the shell:

cat error.log | claude -p "what's going on here?"
git log --oneline -20 | claude -p "summarize recent commits"

"be ambitious": when you want the full version

Claude tends to read requests conservatively and build the smallest version that satisfies them, because it doesn't know how far you expect it to go. When you want something complete, say it directly:

build the settings page from the mockup. be ambitious: empty and error
states, the save flow wired up, keyboard navigation, not just the layout

This is information about scope, which only you know, not a request to "think harder".

"think step by step" is no longer a keyword

According to the docs, phrases like "think step by step" or "be thorough" are now just ordinary text in the prompt. The main control for thinking depth is the effort level (/effort or in /model). Wording can nudge within the current effort level, but can't raise it beyond that.

Let Claude interview you

When you're not sure what you want, don't try to think it all through before prompting. Ask Claude to ask:

I want to add rate limiting to the public API but haven't thought it through.
Interview me until you have enough to write a spec, then write it to SPEC.md.

Claude will ask multiple-choice questions about what you haven't decided: limits per user or per key, how over-limit requests are handled, what's out of scope. Once SPEC.md exists, start a new session to build from it: a clean context, a written definition of "done", and a file reviewers can check against later.

When is a vague prompt fine?

When you're exploring rather than fixing something specific, "what could be improved in this file?" is perfectly reasonable. The tradeoff is more course-correcting along the way. A cost note: requests like "improve the codebase" trigger broad scanning across many files, so they use far more tokens.

Connect tools instead of explaining

• Systems with a CLI (gh, aws…): install and log in, and Claude uses them. For an unfamiliar CLI, just tell it to read --help.
• Systems without a CLI: use MCP, but disable servers you don't need, because tool names and instructions still take context.
• Typed languages: install a code intelligence plugin so Claude jumps straight to definitions instead of reading many files.

How to apply it

• Dev: Practise the formula "location + symptom + definition of done + constraints". Use @file and pipes instead of copy-pasted descriptions.
• Tech Lead: For new features, adopt "interview → SPEC.md → new session to build → review against the spec".
• PM: The interview prompt is a quick way to turn a vague idea into a spec with clear open questions before handing it to the team.