The contractor rule
Imagine hiring a contractor and saying "make my kitchen better." You'd get a kitchen. Now imagine saying "replace the countertops with butcher block, keep the cabinets, budget is $4k, done by March." You'd get your kitchen.
Claude Code is the second contractor — enormously capable, zero mind-reading. Every good prompt carries three things:
- Context — what exists, what this is for, who it's for.
- Outcome — what should be true when it's done. Describe the result, not the method.
- Constraints — what to keep, what to avoid, how simple to stay.
Here's a real prompt from later in this lesson with all three parts lit up:
This page is for a plumbing business whose customers are homeowners in their 50s. Make it feel trustworthy and easy to read: bigger text, more spacing, navy and white color scheme, and put the phone number somewhere impossible to miss. Don't add any animations.
Every strong prompt in this lesson has this skeleton — even when the parts arrive in a different order.
Weak vs. strong, side by side
Same intentions, rewritten. Feel the difference:
Make the page look more professional.
This page is for a plumbing business whose customers are homeowners in their 50s. Make it feel trustworthy and easy to read: bigger text, more spacing, navy and white color scheme, and put the phone number somewhere impossible to miss. Don't add any animations.
Add a contact form.
Add a contact form with three fields: name, email, and message. When someone submits it, I want the message to arrive at my email address. I don't have a server — pick a free service that makes that work from a plain HTML page, and tell me what you picked and why.
One honest footnote on that example: the free form services it'll suggest need a quick signup on your end — it'll walk you through it, but "free" isn't "zero steps."
Fix the layout on phones.
On a phone-sized screen the three cards squish into unreadable columns. Stack them vertically on small screens instead, full width, with space between. Everything else stays as is.
And here's why the wording matters — same request, two different pages:
Notice what the strong ones never do: tell it how to write the code. You describe what a human should experience; the method is its problem. The one time you should absolutely state an opinion about method is simplicity — "keep it one file," "no frameworks," "the simplest thing that works" are magic phrases that prevent overengineering.
Small steps beat big asks
The most common beginner mistake isn't bad wording — it's asking for the whole cathedral in one prompt. "Build me a website with a booking system, a blog, five pages, and a newsletter" produces a mediocre everything, and now you're reviewing fifty things at once.
Work the way you'd renovate: one room at a time. Header first — look at it, fix it, move on. Each step is small enough to judge instantly, and when something's off, you know exactly which instruction caused it. Ten small prompts beat one giant one every single time.
React to what you see
Half of building is the look-and-respond half. Refresh the page, look, then say what you see — literally:
The headline is overlapping the image now, and the whole thing feels cramped on the left side. More breathing room, and the headline should never touch the image.
Describing what's on your screen in plain English is a completely legitimate technique. You're the eyes; it's the hands.
When it gets you wrong, say so bluntly
No feelings will be hurt. The correction formula: that's not it — here's what I meant — try again this way.
That's not what I meant. I didn't want the gallery replaced — I wanted a second section under it. Put the gallery back the way it was, then add a new "Reviews" section below.
Two more moves that pay for themselves:
- Ask before building: for anything chunky, say "Before you write any code, give me a short plan for how you'd approach this." You catch misunderstandings while they're free to fix.
- Ask it to explain: "Explain what this file does in plain English, like I'm not a programmer." It's a patient teacher living inside your builder. Use it.
Homework (10 minutes, in your first-build folder)
Take the page from Lesson 3 and issue three prompts: one strong rewrite of something you'd have asked vaguely, one blunt course-correction, and one "explain this file in plain English." That's the whole toolkit warmed up — next lesson we build the real thing.
You can now…
- Brief like a contractor: context, outcome, constraints
- Turn a weak prompt into a strong one
- Work in small steps and course-correct bluntly
- Ask for a plan before anything big