// 37 tips in Prompting
Tips for writing effective prompts and instructions.
Before jumping to implementation, describe the problem conversationally and let Claude be your thinking partner. It asks clarifying questions, surfaces tradeoffs you haven't considered, suggests approaches, and pokes holes in your plan — so by the time you say "ok, build it," both of you know exactly what to build and why.
Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.
When you need Claude to make changes in one area without affecting another, add negative constraints — "fix the bug but don't change the public API", "refactor the internals but don't create new files", or "update the logic but don't modify any tests." Explicit exclusions prevent Claude from making well-intentioned changes you'll have to undo.
After Claude makes changes to your code, ask it to explain what it did and why it made specific choices. This turns every coding task into a learning opportunity — you understand the reasoning behind the approach, learn patterns you can apply yourself, and catch any decisions you disagree with before moving on.
Instead of describing what code should do, show Claude what it should produce — paste the expected JSON response, HTML output, CLI table, or email template and Claude works backwards to write the code that generates it. The output IS the spec, and there's no room for misinterpretation.
Don't describe your entire feature in one massive prompt. Start with the simplest working version — "create a basic form that saves to the database" — then layer on validation, error handling, edge cases, and polish through follow-up prompts. Each step builds on working code, so you catch problems early and steer the result as it takes shape.
When you tell Claude what to do, also tell it why. "Add rate limiting" is vague — "add rate limiting because our API is getting hammered by a single client causing timeouts for everyone else" gives Claude the context to choose the right approach, scope, and error messages.
Start a line with # in your prompt and Claude treats it as a comment — it's ignored during processing but stays in your input for your own reference. Useful for annotating complex prompts, temporarily disabling instructions, or leaving notes for your future self.
When Claude adds extra features, refactors surrounding code, creates helper functions you didn't need, or makes your simple bug fix into a full rewrite — tell it to do less. "Only change what I asked for, nothing else" keeps Claude focused on the minimum viable change.
When you're learning a framework your project uses — Laravel, React, Next.js — ask Claude to explain how it works using the actual code in front of you, not abstract tutorials. It connects concepts to real implementations you can read, modify, and experiment with.
When you're torn between two implementations — a recursive vs iterative approach, REST vs GraphQL, queue vs cron — show Claude both options and it analyzes the tradeoffs for your specific context, then recommends one with concrete reasoning you can evaluate.
When you need a new controller, component, or service that should match the style of one that already exists, point Claude at the example — "create a ProductController following the same pattern as UserController" — and it replicates the conventions exactly.