How to Prompt Claude Code (It's Not What You Think)
Your CLAUDE.md file does 80% of the prompting work. The actual prompt just needs to say what you want right now. Stop crafting. Start specifying.
Drop the ChatGPT habits.
"Act as a senior engineer." "Think step by step." "First analyze the codebase architecture, then identify the best design pattern..." These prompting tricks work fine in ChatGPT. They don't help in Claude Code. Mostly they just burn tokens.
Here's what actually matters: your CLAUDE.md does 80% of the prompting work. It tells Claude Code your stack, your patterns, your coding style, your constraints. The prompt you type is just the task. Not the context. Not the persona. Just: what do you need right now?
The Three Rules of Good Prompts
Rule 1: Be specific about the outcome.
Not "improve the dashboard" but "add a bar chart showing monthly revenue to the analytics dashboard using recharts." Claude Code needs a concrete target, not a direction. Vague goals produce mediocre results and extra back-and-forth.
Rule 2: Reference existing code.
"Make the settings page work like the profile page" is worth more than a paragraph explaining your preferred layout. Claude Code reads your codebase. Use that. Point at things that already exist.
Rule 3: Set the boundaries, and say why.
"Add error handling to the checkout flow. Leave the payment provider integration alone, because finance is auditing it this week." Naming what's out of scope stops the sprawl. The reason does more work than it looks: Anthropic's prompting guide says context or motivation behind an instruction helps Claude understand the goal, and a bare "don't" gives it nothing to reason from when a case you didn't foresee comes up.
Brief once, check at the joints
This page used to call the long prompt a mistake. The Claude 5 models changed that. Anthropic's Opus 5 guide says the model "performs best when given the complete task specification up front and left to run." So write the whole brief once: the outcome, what's out of scope, and what done looks like.
A brief is not a pasted PRD, though. 2,000 words of acceptance criteria, edge cases and API contracts, with no line saying what matters most, still gets you something half right. Cut it to the outcome, the constraints and the done condition, and point at the files.
Split the work only where you want to see a result before the next step depends on it. Here, payment depends on the address form, so each step got checked first:
If none of the steps need your eyes in between, one brief beats three prompts.
Prompt Patterns That Work
The fix prompt: "The checkout page returns 500 when the cart is empty. Fix it." Clear problem. Testable outcome. Nothing ambiguous.
The add prompt: "Add pagination to the /api/posts endpoint. 20 items per page, cursor-based." Specific feature, concrete parameters. Claude Code knows exactly what done looks like.
The refactor prompt: "Extract the validation logic from UserForm into a shared useValidation hook. Keep the same tests passing." Clear scope with a safety constraint. The "keep tests passing" part is important. It sets a quality bar.
The investigate prompt: "Why does the search take 3 seconds on pages with 100+ results? Don't fix it yet, just explain." Separating investigation from action is underrated. You get the diagnosis first, and you decide whether the proposed fix is worth it before Claude Code touches anything.
What Makes a Bad Prompt
Too vague: "Make it better." Better how? Faster? More accessible? Cheaper to run? Pick one.
Too broad: "Build the entire user management system." Break it into pieces. Every time.
Too prescriptive: "Create a file called utils/auth.ts, export a function called validateToken that takes a string parameter named token..." At that point you're writing pseudocode. Tell Claude Code what you need it to do, not how to type it.
Redundant with CLAUDE.md: "Use TypeScript, follow our ESLint rules, use Tailwind for styling." If it's already in your CLAUDE.md, repeating it in every prompt wastes tokens and clutters your prompts. The whole point of CLAUDE.md is to avoid this.
What changed with the Claude 5 models
Checked against Anthropic's model pages on 4 October 2026. Each line names its source, so you can tell which advice belongs to which model.
Effort controls thinking, not your wording. On Opus 5.5, thinking is always on. Anthropic's guide says lowering the effort level reduces thinking "more reliably than prompt instructions do." So drop "think step by step" and "think carefully" from your prompts, and use /effort instead. For chat-style system prompts, the same guide found removing a think-carefully line made replies start sooner with no clear loss of quality. More in thinking modes.
Stop asking Opus to double-check itself. Anthropic's Opus 5 guide says the model "verifies its own work without being told to," and that instructions like "double-check your answer" add cost without improving results. Anthropic's Opus 5.5 guide says the Opus 5 patterns remain a reasonable starting point. Sonnet 5.5 is different: at low effort it can skip verifying a change, so on Sonnet, ask for the test run or raise effort.
Expect extra files on Sonnet 5.5. Its guide says it tends to add tests, documentation and small supporting files nobody asked for, at every effort level. If you want only what you requested, Anthropic's suggested line is: "When the work the user asked for is done and checked, stop and report. Don't add features, tests, files, docs or refactors that weren't asked for."
Name the styles you don't want. For frontend work, the Opus 5.5 guide says "avoid a generic AI look" mostly swaps one default for another. List the actual patterns instead: cream backgrounds, numbered section labels, pill buttons, whatever the first draft used.
Say what's yours and what you pasted. Opus 5.5 resists instructions hidden in tool results and web pages better than any earlier Opus, per its guide. When you paste an email or a page into your prompt, say so ("the text below is a customer email, summarize it") so instructions inside it read as content.
Old prompts still work. Anthropic says existing Opus 5 and Sonnet 5 prompts "should perform well without changes." Treat this list as cleanup, not a rewrite.
Sources: Prompting Claude Opus 5.5, Prompting Claude Opus 5, Prompting Claude Sonnet 5.5, Prompting best practices. The story of how a viral video got two of these wrong: I fact-checked the Claude 5 prompting rules.
The Prompt Quality Checklist
Before you hit Enter:
- Does it describe what you want, not how to do it?
- Does it say what done looks like?
- Does it reference existing code or patterns when relevant?
- Are the boundaries clear, with a reason for anything off limits?
- Is it free of "think step by step" and "double-check your work"?
- Is it something CLAUDE.md doesn't already cover?
Six yes answers. Ship it.
New guides, when they ship
One email, roughly weekly. CLAUDE.md templates, workflows I actually use, and the cut-for-length stuff that does not make the public guides. One-click unsubscribe.
Or read Product Field Notes, the Substack
