// 48 tips tagged "prompting"
When Claude writes error messages, button labels, validation text, or onboarding flows, it defaults to generic developer-speak. Add a "Users" section to your CLAUDE.md describing who your actual users are — their technical level, industry jargon, and what they care about — so Claude writes copy that makes sense to THEM, not to developers.
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.
Unlike --system-prompt which replaces everything, --append-system-prompt layers additional instructions on top of your existing CLAUDE.md and default system prompt. Keep all your project context and just add a temporary constraint or focus area for one session.
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.