Most bad sessions have the same few causes
When a session goes sideways, it's almost always one of these:
- Claude is missing information: something that isn't in the repo, or is slow to rediscover.
- Claude has no check to run, so it can't tell success from failure.
- A rule needs enforcement, not a request. (That's a job for hooks, Unit 7.)
This lesson tackles the first two, which you control in every prompt you write.
The "what can't it see?" test
Before you hit Enter, ask: what do I know that Claude can't find by reading the repo?
pnpm test -- checkout.large. Expected: order created. Stack trace attached."pnpm bench reports, find the top cost and get it under 1s without changing the API."Things Claude typically can't see: the bug report, the customer's exact words, decisions made in meetings, which approach the team already rejected, production-only behavior and deadlines.
Give it a check
The single highest-leverage habit: tell Claude how to verify success.
- A test command: "run
pnpm test -- billingafter each change" - A build or typecheck: "
cargo buildmust succeed with no warnings" - A reproduction: "this curl should return 201"
- A visual target: paste a screenshot of the design and ask Claude to compare
implement the empty-state design in the attached screenshot. then run the dev server,
screenshot the page and compare it to mine. list any differences and fix them.Feed it context directly
- Files:
@src/billing/invoice.tspulls a file in. - Images: paste with Ctrl+V or drag in screenshots of bugs, designs and diagrams.
- Pipes:
cat error.log | claude -p "explain the root cause" - URLs: "read https://… and apply its migration guide"
- CLIs: "use
gh issue view 312to read the bug report"
Be specific about scope
Claude can be ambitious, which is great when you want it and costly when you don't. Say which you want:
minimal fix only: don't refactor surrounding code, don't rename anything.be ambitious: this is a greenfield prototype, propose a clean architecture.Effort, not magic words
Rather than sprinkling "think hard" into prompts, control reasoning directly with effort levels. /effort sets how much reasoning Claude puts in: medium is the default, high for subtle work, low for fast iteration. Including ultrathink in a prompt raises effort for that one turn.
ALL-CAPS "IMPORTANT" lines, "think step by step", "keep going" and long architecture descriptions Claude could read from the code. Modern Claude Code doesn't need them. Clear context and a concrete check do far more.
Check your understanding
Which prompt is strongest?
What's the highest-leverage addition to most prompts?
How do you raise reasoning effort for a single turn?
Which is something Claude typically CAN'T see?