01 · The problem
Why good tools give bad results
Claude Code is capable of extraordinary things, but it only does what you actually ask. Most disappointing results come from the prompt, not the model.
"I used to think Claude just wasn't that good. Turns out I was prompting it like a search engine. Once I changed that, everything changed."
Developer, six weeks into their Claude Code practice❌ Weak prompt
"Fix the bug in the login function."
✓ Strong prompt
"In auth/login.js, the validateToken() function returns undefined instead of false when the token is expired. Find the bug, explain why it's happening, fix it without changing the function signature, and add a test case that would have caught this."
The three failure modes
Most bad prompts fail in one of three ways:
Too vague: Claude guesses what you mean and guesses wrong. "Fix this" with no context.
Too open-ended: Claude produces something technically correct but not what you needed. "Improve this function."
Missing constraints: Claude solves the problem in a way that creates new ones. "Refactor this" without saying what to preserve.
Too vague: Claude guesses what you mean and guesses wrong. "Fix this" with no context.
Too open-ended: Claude produces something technically correct but not what you needed. "Improve this function."
Missing constraints: Claude solves the problem in a way that creates new ones. "Refactor this" without saying what to preserve.
01 / 05
02 · The structure
Anatomy of a strong prompt
Strong prompts aren't longer; they're more structured. Five components, use what's relevant.
Prompt anatomy: five components
ROLE
Set the perspective. "Act as a security reviewer..." or "You're a senior Rails developer...". This primes Claude's reasoning style, not just its vocabulary.
CONTEXT
Locate the work. File name, function name, what the surrounding code does. "In
src/api/payments.js, the chargeCard() function currently..." Context beats lengthy pasting.
TASK
State the action clearly. Use verbs: Find, Explain, Write, Refactor, Add, Remove, Trace, List. One main task per prompt works better than a list of five things.
FORMAT
Specify the output. "Return bullet points," "Show a diff only," "Give me just the function, no explanation," "Write it as a code comment." Claude defaults to verbose. Tell it not to be.
GUARDRAILS
State what not to do. "Don't change the function signature." "Don't add new dependencies." "Don't rewrite, just fix this one issue." Guardrails prevent solving the right problem the wrong way.
You don't need all five every time
A simple question needs a simple prompt. The anatomy is a checklist for when something isn't working, not a template you fill out every time. If Claude misses the mark, ask: which component was I missing? Usually it's context or guardrails.
❌ Missing format + guardrails
"Write tests for the payment module."
✓ With format + guardrails
"Write unit tests for chargeCard() in payments.js. Use Jest. Test the happy path and the card-declined case only. Don't test the Stripe SDK internals. Mock those. Return just the test file."
02 / 05
03 · Patterns that work
Six prompting patterns to memorize
These reusable patterns cover 80% of daily Claude Code interactions. Learn them once, apply them forever.
The Explainer
Understand
When · Unfamiliar code, complex logic, or onboarding
"Explain [thing] to me as if I'm a competent developer who hasn't seen this codebase before. Use an analogy if it helps. Keep it under 100 words."
The word limit forces Claude to be precise, not comprehensive.
The Diff Driver
Edit
When · You know what to change, not how
"Change [X] to [Y] in [file]. Show me the diff before writing. Don't change anything else."
Explicit diff request + scope limit prevents scope creep and surprises.
The Impact Check
Safety
When · Before any significant change
"If I [change/remove/refactor] [X], what could break? List callers, dependents, and assumptions that rely on current behavior. Don't make any changes yet."
"Don't make any changes yet" is critical: without it, Claude may proceed.
The Test-First Writer
Quality
When · Adding or changing behavior
"Write failing tests for [feature] first. I'll review them, then we'll implement the code to make them pass. Use [test framework]. Tests only for now."
Separating test and implementation into two turns improves both.
The Constraint Setter
Control
When · Claude keeps over-engineering
"Solve this in the simplest possible way. No new abstractions, no new files, no new dependencies. The fix should touch as few lines as possible."
Claude defaults to thorough. This pattern forces minimal, surgical changes.
The Options Asker
Decision
When · You're not sure what approach to take
"Give me three different approaches to [problem], each as a bullet: approach, tradeoff, and when you'd choose it. Don't implement any of them yet."
Forces Claude to think in options instead of jumping to one solution.
03 / 05
04 · When it doesn't work
The iteration loop
The best prompt isn't the first one; it's the refined one. Here's the loop experienced Claude Code users run when a result misses the mark.
1
Send your first prompt
Start specific, not perfect. The goal is to get Claude engaged with the right problem. You'll sharpen it in the next step.
2
Diagnose the miss
Wrong direction? Missing context. Right direction, wrong scope? Missing guardrails. Too verbose? Missing format constraint. Right answer, wrong code? Missing location context.
3
Correct in plain English
Don't restart, refine.
"That's close, but..." or "Focus only on X, ignore Y" or "Too long, summarize in 3 bullets". Claude holds context across turns.4
Verify before accepting
Before accepting a code change, ask:
"What could go wrong with this approach?" Claude's self-critique often surfaces edge cases it didn't account for the first time.5
Save what worked
When a prompt sequence works well, copy it to your personal prompt library or your CLAUDE.md file. The best prompts compound over time.
Anti-pattern Restarting instead of refining
When Claude misses the mark, the impulse is to
/clear and start over. Resist it. Claude holds context across the conversation. A correction in the same thread is almost always faster and gets better results than starting cold. Only clear when the conversation has genuinely gone in the wrong direction.💡 Asking Claude to critique its own output works better than you'd expect. "What are the weaknesses in what you just wrote?" before accepting a code change is one of the highest-ROI habits you can build this week.
04 / 05
05 · Your outcome
Practice exercises & checklist
Apply each pattern to a real file in your current project. Ten minutes each.
Exercise 1Anatomy
Take a prompt that got a bad result recently
Rewrite it using the five-component anatomy. Add the missing piece (usually context or guardrails), run it, and compare the results. Write what changed.
Exercise 2Critique loop
On any Claude Code output today
After it responds, follow up with: "What are three weaknesses in that approach? What edge cases didn't you consider?" Then decide whether to proceed or refine.
Exercise 3Pattern practice
Pick one function you're nervous about changing
Run the Impact Check pattern on it. Then run the Options Asker on how to change it. Don't implement anything, just use Claude to think through the decision.
A prompt that worked today: save it
A pattern you'll use again tomorrow
Day 04 checklist
- Rewrote a weak prompt using the five-component anatomy
- Used at least two of the six named patterns on real code
- Asked Claude to critique its own output at least once
- Refined a result without restarting the conversation
- Saved one strong prompt to my personal prompt library or CLAUDE.md
- Can name the five anatomy components from memory
05 / 05
Day 04 complete
You have a prompt framework that works. Tomorrow is Day 05: Making Real Edits. You'll use these prompting skills to make your first significant code changes with confidence.
Your prompt library is a long-term asset. Keep adding to it every day.