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 to leave alone, and how to prove the change works. For setup and everyday habits, read our 20 Claude Code Tips guide.

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

Task

What to build, fix, or change

Context

Relevant files tagged with @, plus errors and links

Constraints

Style, libraries, and what must stay untouched

Done means

Tests pass, the behavior works, and the output looks right

Process

Plan first, ask questions, or go straight ahead

• Tag exact files with @
• Paste the complete error message
• Attach screenshots for UI work
• Store project rules in CLAUDE.md so you never repeat them

Read @src/checkout and @tests/checkout. Propose a plan for adding discount codes, with the files to change and the risks. Do not edit anything yet.

Switch to plan mode for larger changes, then approve the plan.

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

On Safari, users get a blank page after login. Console error: [error]. Find the root cause, explain it in two sentences, fix only that cause, and add a test that would have caught it.

Split @src/utils/date.ts into smaller functions without changing its behavior. Keep the public API identical, and run the tests both before and after.

Write tests for @src/cart.ts that cover empty carts, discounts, and rounding. Follow the patterns in @tests/order.test.ts. Leave the source code untouched.

• “Check my changes for bugs, security issues, and missing tests.”
• “Explain how authentication works in this project, citing the files.”
• “What might break if I upgrade this library?”

• Press Esc the moment it heads the wrong way
• State exactly what went wrong and what to do instead
• Rewind to an earlier point when you need to
• Ask it to keep the change smaller

Revert the changes to the API layer. Change only the UI component, and keep its existing props.

• Lower effort for simple edits and quick questions
• Higher effort for tricky bugs and architecture work
• A fresh session via /clear for every new task

• Saying “make it better” without defining better
• Bundling many unrelated changes into one request
• Leaving no way to check the result
• Letting it edit files you never mentioned