Claude Code Prompt Tips That Work

Prompting Claude Code is different

If you have used ChatGPT or Claude.ai for coding, you have built prompting habits that work in a chat interface. Some of those habits transfer to Claude Code. Many do not.

Claude Code is not a chatbot. It is a terminal agent with direct access to your filesystem, shell, and project context. It can read every file in your project, run commands, and modify code directly. This changes what good prompts look like.

In a chat interface, you paste code into the prompt because the AI cannot see your files. In Claude Code, you reference files by path. In a chat interface, you describe your project structure because the AI has no context. In Claude Code, the AI reads your codebase before responding.

The prompts that work best in Claude Code are shorter, more direct, and more action-oriented than chat prompts. Here is how to write them.

Rule 1: Reference, don't describe

The most common mistake when switching to Claude Code is over-describing things that Claude Code can see for itself.

Weak prompt:

I have a React component called UserProfile that takes a user
object with name, email, and avatarUrl fields. It renders a
card with the user's info. I want to add a loading state.
The component is in src/components/UserProfile.tsx and uses
Tailwind for styling...

Strong prompt:

Add a loading skeleton state to src/components/UserProfile.tsx.
Match the skeleton style used in src/components/TeamList.tsx.

The strong prompt is shorter and produces better results. Claude Code reads both files, understands the component structure, prop types, and styling patterns without you explaining any of it. Your job is to point to what exists and say what you want changed.

This principle extends to everything. Don't describe your database schema when Claude Code can read your schema file. Don't explain your API structure when Claude Code can scan your routes directory. Don't paste error messages when Claude Code can run the command and see the error directly.

Point. Don't describe.

Rule 2: Be specific about the outcome

Vague prompts produce vague results. This is true for all AI tools, but Claude Code amplifies the effect because it can take action. A vague prompt in ChatGPT gives you a vague answer. A vague prompt in Claude Code gives you vague code changes to real files.

Vague:

Make the authentication better.

Specific:

Add rate limiting to the login endpoint at src/api/auth/login.ts.
Limit to 5 attempts per email per 15 minutes. Return a 429 status
with a retry-after header when exceeded. Store attempt counts
in Redis using the existing client at src/lib/redis.ts.

The specific prompt tells Claude Code exactly what to build, where to build it, what constraints to follow, and which existing infrastructure to use. The result is code you can merge without significant revisions.

You don't need to specify every implementation detail. Claude Code fills in the gaps intelligently. But you should be specific about:

• What you want (the feature or change)
• Where it goes (file paths or component names)
• Constraints (performance limits, API compatibility, style matching)
• Dependencies (which existing code to use or follow)

Rule 3: Use "follow the pattern" prompts

One of Claude Code's strongest capabilities is pattern matching across your codebase. It reads your existing code and replicates conventions automatically. Leverage this.

Create a new API route for /api/invoices following the same
pattern as /api/orders. Same error handling, validation
approach, and response format.

This single sentence carries more information than a page of specification. Claude Code reads the orders route, extracts the pattern (middleware, validation library, error response shape, naming conventions), and applies it to invoices. The result matches your codebase perfectly because it was derived from your codebase.

Pattern prompts work for:

• New components that match existing ones
• Test files that follow your testing conventions
• Database migrations that match your schema style
• API endpoints that use your established patterns

The syntax is simple: "Follow the pattern in [existing file]" or "Match the style of [reference]." Claude Code does the analysis.

Rule 4: Add verification steps

Claude Code can check its own work. Most developers forget to ask it to.

Refactor src/utils/date.ts to use date-fns instead of moment.
After refactoring:
1. Run `npm test` to verify nothing breaks
2. Check that the bundle size decreased
3. Search the codebase for any remaining moment imports

The verification steps turn a one-shot prompt into a self-correcting workflow. If the refactoring breaks tests, Claude Code sees the failures and fixes them. If moment imports remain elsewhere, Claude Code catches them.

Good verification steps include:

• Run the tests after any code change
• Check for TypeScript errors after type modifications
• Verify no console.log statements remain after debugging
• Confirm the build succeeds after dependency changes
• Search for TODO comments I added before marking work as done

This pattern alone will save you more time than any other prompting technique. Instead of reviewing Claude Code's output, running tests manually, finding issues, and going back to fix them - you let Claude Code close the loop itself.

Rule 5: Iterate with corrections, not rewrites

When Claude Code's first output isn't quite right, don't start over. Correct it.

Rewrite approach (wasteful):

Actually, forget that. Let me try again. Create a UserProfile
component that has a loading state and shows a skeleton...
[re-explains everything from scratch]

Correction approach (efficient):

Good, but two changes:
1. The skeleton should pulse, not shimmer
2. Show 3 skeleton lines for the bio, not 2

Claude Code maintains conversation context. It remembers what it just did, which files it modified, and what your intent was. Short corrections build on that context instead of discarding it.

This mirrors how you would direct a human colleague. You wouldn't re-explain the entire task when they get one detail wrong. You would say "change X to Y" and they would understand from context.

Effective corrections are:

• Specific: "Change the border radius from 8px to 12px" not "make it rounder"
• Additive: "Also add a hover state" not "redo it with a hover state"
• Referenced: "In the function you just created, add error logging" not "add error logging somewhere"

Rule 6: Use CLAUDE.md for persistent context

Some prompting context applies to every interaction, not just one. Your code style preferences. Framework conventions. Things Claude Code should always do or never do.

Instead of repeating these in every prompt, put them in your CLAUDE.md file:

# CLAUDE.md

## Code Style
- Use TypeScript strict mode
- Prefer named exports over default exports
- Use biome for formatting (not prettier)
- Error messages must be user-facing readable

## Conventions
- API routes return { data, error } shape
- All database queries go through the repository pattern
- Tests use vitest with the testing-library

With this file in place, every prompt you type inherits these constraints automatically. You stop saying "use TypeScript" and "follow our error format" in every prompt because Claude Code reads CLAUDE.md at the start of every session.

Think of CLAUDE.md as a permanent system prompt for your project. Custom commands are reusable prompts for specific tasks. Together, they eliminate most of the repetitive context-setting that makes prompting tedious.

Rule 7: Scope matches quality

There is an inverse relationship between prompt scope and output quality. The more you ask for in a single prompt, the more likely Claude Code is to miss details or make trade-offs.

Too broad:

Build a complete user management system with registration,
login, password reset, email verification, role-based access
control, and an admin panel.

Right-sized:

Create the user registration endpoint at src/api/auth/register.ts.
Accept email and password. Hash the password with bcrypt. Store
in the users table. Return a JWT. Follow the pattern in
src/api/auth/login.ts.

The right-sized prompt produces production-ready code on the first attempt. The broad prompt produces a rough draft that needs significant revision.

A good rule of thumb: if the task would take a human developer more than 2 hours, break it into multiple prompts. Each prompt should produce a complete, testable unit of work.

This matters more in Claude Code than in chat interfaces because Claude Code makes real changes. A chat response you can ignore. A broad Claude Code prompt might modify 15 files in ways that are hard to review and partially wrong.

What to do when prompts don't work

Sometimes a well-crafted prompt still produces wrong output. Before blaming the prompt, check these common issues:

Claude Code lacks context. If your project uses an unusual convention, Claude Code might not find it from file scanning alone. Add it to CLAUDE.md or reference the specific file that demonstrates the convention.

The task is ambiguous. "Fix the bug" assumes Claude Code knows which bug. "The /api/users endpoint returns 500 when the email contains a + character" is unambiguous. If you find yourself saying "no, I meant..." frequently, your prompts have ambiguity.

The scope is too large. Watch for prompts that produce "almost right" results across many files. This usually means the task should be split. Each sub-task will get full attention instead of shared context.

You are fighting the model's instincts. If Claude Code keeps doing something you do not want - like adding comments to every function - add a constraint to CLAUDE.md rather than correcting it per-prompt. Persistent behaviors need persistent instructions.

Check out our Claude Code tips guide for more techniques that address these common friction points.

Before and after: real prompt upgrades

Here are five real prompts, upgraded from weak to strong:

Weak	Strong
"Add tests"	"Write vitest tests for src/utils/pricing.ts covering edge cases. Match the style in src/utils/tests/formatting.test.ts"
"Fix the CSS"	"The sidebar in src/components/Sidebar.tsx overlaps the main content below 768px. Add a responsive breakpoint that collapses it to a hamburger menu"
"Refactor this file"	"Split src/api/handlers.ts into separate files per resource under src/api/handlers/. Keep the same exports so existing imports don't break"
"Make it faster"	"The /api/search endpoint takes 3s on average. Add a Redis cache layer with 5-minute TTL. Use the existing Redis client at src/lib/redis.ts"
"Update the docs"	"Update the API section of docs/README.md to include the new /api/invoices endpoints. Follow the same format as the /api/orders section"

The pattern is consistent: strong prompts name files, reference patterns, specify constraints, and define what "done" looks like.

Frequently asked questions

Should I use natural language or pseudo-code in prompts?

Natural language works better in Claude Code. Unlike chat interfaces where pseudo-code helps bridge the gap between intent and implementation, Claude Code reads your actual code for implementation context. Your prompt should describe what you want, not how to implement it. The exception is algorithm-specific logic where the implementation approach matters - in those cases, outlining the algorithm in pseudo-code prevents Claude Code from choosing a different approach.

How long should a Claude Code prompt be?

Most effective prompts are 2-6 lines. Longer prompts work when the task is genuinely complex, but length often signals that you are over-describing context Claude Code can find itself. If your prompt exceeds 10 lines, check whether you are describing things Claude Code could read from files instead. The best prompts are short on description and specific on intent.

Do I need to use special formatting or syntax?

No special syntax is required. Markdown formatting (bullet lists, code blocks) helps organize complex prompts but plain English works fine. The one format that consistently helps is numbered steps for multi-phase tasks - they give Claude Code a clear execution order and make it easier to spot if a step was skipped.

Build better prompts faster

Good prompting is a skill that improves with practice. Start with the rules in this guide, pay attention to which prompts produce first-attempt results versus which need corrections, and adjust your patterns accordingly.

If you want to skip the learning curve, Claudify ships with 21 pre-built commands that encode proven prompting patterns for common workflows. They are production-tested prompts wrapped in slash commands - code review, testing, deployment, quality auditing, and more. One install command: npx create-claudify.

Get Claudify - production-tested prompts and workflows, ready to use.