How to Prompt Claude Code

Claude Code can read your project, edit files, and run commands. A clear prompt tells it what to change, what not to touch, and how to prove the change works. For setup and general habits, see our 20 Claude Code Tips guide.

Vague prompts get big, surprising diffs. Clear prompts get small, correct ones.

Task

What to build, fix, or change

Context

Relevant files with @, errors, and links

Constraints

Style, libraries, and what not to change

Done means

Tests pass, behavior works, output looks right

Process

Plan first, ask questions, or go ahead

• Mention exact files with @
• Paste the full error message
• Share screenshots for UI work
• Keep project rules in CLAUDE.md, so you do not repeat them

Read @src/checkout and @tests/checkout. Propose a plan to add discount codes, listing files to change and risks. Do not edit anything yet.

Use plan mode for bigger changes, then approve the plan.

Add a dark mode toggle to the settings page. Use the existing theme hook in @src/theme.ts, store the choice in local storage, and match the current toggle styles. Done means the toggle works, the choice persists after reload, and existing tests pass.

Users see a blank page after login on Safari. Here is the console error: [error]. Find the root cause, explain it in two sentences, fix only that, and add a test that would have caught it.

Refactor @src/utils/date.ts into smaller functions without changing behavior. Keep the public API the same, and run the tests before and after.

Write tests for @src/cart.ts covering empty carts, discounts, and rounding. Follow the patterns in @tests/order.test.ts. Do not change the source code.

• “Review my changes for bugs, security issues, and missing tests.”
• “Explain how authentication works in this project, with file references.”
• “What could break if I upgrade this library?”

• Press Esc to stop as soon as it goes the wrong way
• Say exactly what was wrong and what to do instead
• Rewind to an earlier point when needed
• Ask it to keep a change smaller

Undo the changes to the API layer. Only change the UI component, and keep the existing props.

• Lower effort for simple edits and questions
• Higher effort for tricky bugs and architecture
• Start a fresh session with /clear for new tasks

• “Make it better” with no definition
• Asking for many unrelated changes at once
• No way to check the result
• Letting it change files you did not mention