This chapter teaches you the art of prompting, how to phrase your requests to get exactly what you want on the first try. This is THE skill that makes all the difference. Reading time: 10 minutes.
The golden rule
Be precise about the WHAT and the WHY. Let Claude handle the HOW.
You don't need to know how to code to give a good instruction. You need to know what you want and why you want it. Claude takes care of the technical translation.
The 5 types of prompts
1. Create something new
You want a new page, a component, a feature.
Vague: "Make me a login page."
→ Claude will make random choices: which design? Which fields? Which redirect after login? Which error message?
Precise: "Create a login page with email and password. Use Supabase Auth. After successful login, redirect to /app. If the email doesn't exist, show 'No account found with this email' in red below the field. If the password is incorrect, show 'Incorrect password'. Follow the project's palette."
→ Exact result on the first try.
What makes the difference: the acceptance criteria. Instead of "make a page", describe what should happen when it works AND when it doesn't.
2. Fix a problem
Something doesn't work. Describe what you observe vs what you expected.
Vague: "The button doesn't work."
→ Which button? On which page? What happens when you click? Nothing at all? An error? The wrong behavior?
Precise: "On the /app/strategy page, when I click the 'Generate my strategy' button, nothing happens. I expect to see a loading state then the generated strategy appear below. The button stays clickable, no spinner, no error in the console."
3. Understand existing code
You want to understand how something works before modifying it.
"Explain how the brand scoring system works. Show me the files involved and the data flow from calculation to display."
"Walk me through a user's journey from sign-up to their first content generation. Which files are touched?"
Claude will navigate the code and explain it as if you were a curious colleague, not a developer.
4. Iterate on a result
The first draft is rarely perfect. 2-3 iterations = excellent result.
"The form works well but I'd like to add real-time validation on the email field, so it checks the format while typing, not just on submit. And disable the button as long as the form isn't valid."
"The page is functional but the design is too basic. Add subtle shadows on the cards, more generous spacing between sections, and a subtle animation when the data loads."
5. Explore options
Before building, explore the possibilities.
"What are my options for adding a notification system to the app? Compare email, push, in-app, and webhook. Give the pros and cons of each for a B2B SaaS with 100-500 users."
Claude will compare the approaches with concrete criteria: cost, complexity, UX, maintenance.
Magic phrasings
Some phrasings unlock very powerful Claude behaviors:
| Phrasing | What it triggers |
|---|---|
| "Brainstorm..." | Claude explores 3-4 approaches with pros and cons before writing any code |
| "Plan the implementation of..." | Claude produces a numbered plan task by task with the files involved |
| "Execute the plan in..." | Claude reads the plan and executes it sequentially with checks between each step |
| "Verify everything compiles and tests pass" | Claude runs typecheck + lint + tests and fixes errors in a loop |
| "Update the project memory" | Claude saves the decisions made for the next sessions |
| "Do it in parallel" | Claude runs multiple independent tasks at the same time (faster) |
| "ultrathink" | Forces deep reasoning. Claude takes more time but produces deeper thinking. Ideal for complex architecture problems |
Two advanced techniques that change the game
ASCII diagrams
Claude understands text diagrams very well. When you want to explain an architecture, a data flow, or a relationship between modules, draw it in ASCII instead of writing it in sentences:
User → Login page → Supabase Auth
↓
Session cookie
↓
Middleware checks auth
↓
Page /app (Server Component)
↓
Server Action + RLS auto
Claude integrates this diagram and produces code consistent with the architecture described. It's often clearer than 3 paragraphs of explanation.
Screenshots
When you're stuck on a visual problem (display bug, browser error, console error), take a screenshot and share it with Claude.
Claude Code is multimodal: it can read images. A screenshot instantly shows:
- The exact error in the console
- The visual rendering of the problem
- The page context
Habit to build: as soon as you see a visual bug, take a screenshot and send it with "Here's what I see, here's what I expect". It's 10x faster than describing the problem in text.
The trick that changes everything: business context
Claude is dramatically better when it understands the business why, not just the technical what. This is your unique added value, you're the one who knows your users.
With business context:
"Freelancers using our app often forget to publish their scheduled content. Build a reminder system that sends an email the day before each scheduled publication in the calendar. Tone: encouraging, not guilt-inducing. Email subject: include an emoji and the content title."
Without context:
"Add reminder notifications."
→ Claude doesn't know: when to trigger? Which channel (email, push, in-app)? What tone? Which data to include?
The more business context you give, the fewer iterations you'll need. A good prompt with context = 1 try. A vague prompt = 3-4 back-and-forths.
The structure of a perfect prompt
Here's the template I use for complex requests:
- Context: why this feature exists (which user problem it solves) 2. What: what you want to build (functional description) 3. Criteria: what should happen when it works AND when it doesn't 4. Constraints: technical, design, or business limits to respect
Full example:
Context: our pro users pay $29/month and want to know how many pieces of content they've generated this month compared to their plan.
What: a progress bar component on the dashboard that shows the current month's AI usage (number of generations used / plan limit).
Criteria: show "12 / unlimited" for Pro, "2 / 2" for Free with the bar in red when full. When a Free user hits their limit, show a "Go Pro" button.
Constraints: use the data from the
ai_usagetable in the DB. Follow the project's palette. Reusable component.
The most common communication mistakes
| Mistake | Why it's a problem | How to fix |
|---|---|---|
| "Improve the page" | Too vague, improve what? The design? Performance? UX? | "Add a loading animation and better spacing between sections" |
| "Do it like the other page" | Claude doesn't know which page you want to copy | "Use the same layout as the /app/strategy page: sidebar + main content" |
| "It's not pretty" | Subjective and not actionable | "The cards are too cramped, add 16px gap. The title is too small, bump it to 2xl." |
| Sending a screenshot without context | Claude sees the image but doesn't know what to look for or fix | Always add "Here's what I see, here's what I expect" with the screenshot |
Takeaway: a precise prompt with business context = result on the first try. A vague prompt = 3-4 back-and-forths. Invest 30 extra seconds in your phrasing, save 10 minutes of corrections.