Smart Prompting Techniques

Lesson content

The difference between a frustrating Claude Code session and a magical one usually comes down to one thing: how you ask. The quality of your prompt directly determines the quality of Claude's output. In this lesson, you'll learn the patterns that separate beginners from power users.

The Anatomy of a Bad Prompt

Let's start with what NOT to do. These prompts produce vague, wrong, or incomplete results:

"Fix the login" — Fix what? Where? What's broken?
"Make it faster" — What is "it"? Which part? How do you measure "faster"?
"Add tests" — For which functions? What kind of tests? What should they verify?
"It doesn't work" — What did you expect? What actually happened?

These prompts fail because they assume Claude has the same context as you. It doesn't. Claude reads your files but doesn't know what you're looking at, what you just tried, or what "it" refers to.

The Anatomy of a Good Prompt

A good prompt includes four elements: What, Where, Why, and How to verify.

Compare this transformation:

Bad Prompt	Good Prompt
"Fix the login"	"In src/auth/login.ts, the handleSubmit function throws a TypeError when email is empty. Add validation before the API call to check that email is a non-empty string."
"Add a button"	"In src/components/Header.tsx, add a 'Sign Out' button next to the user avatar. Use the LogOut icon from lucide-react. On click, call the signOut() function from next-auth."
"Make it responsive"	"The pricing cards in src/landing/Pricing.tsx stack vertically on mobile but the gap is too large. Change the gap from gap-8 to gap-4 on screens below md breakpoint."
"It doesn't work"	"Running npm run build fails with 'Module not found: @/lib/stripe'. I removed the Stripe integration yesterday. Find all remaining imports of @/lib/stripe and remove them."
"Add dark mode"	"Add a dark/light mode toggle to the Settings page at src/app/settings/page.tsx. Store the preference in localStorage under key 'theme'. Use the Sun and Moon icons from lucide-react for the toggle."
"Write docs"	"Create JSDoc comments for all exported functions in src/lib/utils.ts. Include @param types, @returns description, and a one-line @example for each function."

Provide Context: What, Where, Why

Every prompt should answer three questions:

What — What specifically needs to change? Be precise about the behavior.
Where — Reference files by their exact path. Claude can read them, but telling it which file to look at saves time and prevents it from guessing.
Why — Explain the reason behind the change. When Claude understands the "why", it makes better architectural decisions.

For example: "In src/components/PaymentForm.tsx, change the currency display from USD to the user's locale currency. We're expanding to international markets and users are confused by dollar signs."

The "why" (international expansion, user confusion) helps Claude make decisions you haven't explicitly stated — like also updating error messages and confirmation text to be locale-aware.

Reference Files by Path

One of the most powerful habits is referencing files by their exact path:

// Instead of:
"Update the header component"

// Say:
"In src/components/layout/Header.tsx, add a notification bell icon
between the search bar and user avatar"

When you name the file, Claude immediately reads it, understands the existing code structure, and makes changes that fit perfectly. Without a file path, Claude might find the wrong file, create a new one, or make changes that conflict with existing code.

Tell Claude the "Why", Not Just the "What"

This is the single most underrated prompting technique. Compare:

What only: "Add a 2-second delay before the API call in handleSubmit."

What + Why: "Add a 2-second debounce before the API call in handleSubmit. Users are accidentally double-submitting the form, causing duplicate payments."

With the "why", Claude might also add a loading state, disable the button during submission, and add an idempotency key — all without being asked. It understood the real problem, not just the surface-level fix.

The Iteration Pattern

Perfect prompts on the first try are rare. The real skill is in the iteration loop:

Request — Give Claude a clear initial prompt
Review — Read what Claude produced. Check the logic, the UI, the edge cases.
Refine — Give specific feedback: "The button looks good but move it 8px to the right and change the hover color to orange-600"

Each iteration gets you closer to exactly what you want. Don't try to describe everything perfectly upfront — it's faster to iterate in 2-3 rounds than to write a 500-word prompt.

Power Patterns

Here are advanced prompting patterns used by experienced Claude Code users:

Constraint setting: "Do NOT modify any files outside the src/auth/ directory"
Format specification: "Use the same code style as the existing functions in this file"
Scope limiting: "Only change the mobile layout — don't touch desktop styles"
Output request: "After making changes, show me a summary of what you changed and why"
Reference pointing: "Look at how we handle this in src/components/UserCard.tsx and follow the same pattern"

Common Mistakes to Avoid

Even experienced users fall into these traps:

Over-prompting: Writing a 1000-word specification when 2 sentences would do. Start simple, iterate.
Under-prompting: Saying "build me an app" and expecting a complete product. Break it into small, specific tasks.
Not reading Claude's output: Claude explains what it did and why. Read it. Sometimes it flags issues you didn't notice.
Ignoring context: If Claude asks a clarifying question, answer it. It's asking because the prompt was ambiguous.

Tip: Before sending a prompt, ask yourself: "If a new developer on my team received this instruction, would they know exactly what to do?" If not, add more specifics.

The best prompt is the one that would make sense to a talented colleague who's new to your project. Specific, contextual, and purposeful.

Smart Prompting Techniques

Lesson format

Access

Lesson content