Brief the outcome. Direct the result.

Outcomes, not steps

The classic beginner mistake is trying to sound technical — guessing at instructions for a discipline you don't practice. Don't. Claude knows the steps; what it can't know is your intent. Compare:

• Weak: "Make an HTML file with a div and put some CSS on it."
• Strong: "I want a page my clients land on after booking. It should confirm their session, look calm and reassuring, and tell them the three things to do before we meet."

The strong brief contains zero technology and every piece of information Claude actually needed. Purpose, audience, feeling, content. That's your half of the deal.

The anatomy of a good brief

Five ingredients, in whatever words come naturally:

1. Goal — what this thing is for, in one sentence.
2. Audience — who sees it and what they should feel or do.
3. Content — the actual words, links, or facts to include (or permission to draft them for you).
4. Taste — tone, colors, one or two sites or things you admire.
5. Boundaries — what not to touch, and how much to check in.

Goal: [what you're making and why, one sentence]
Audience: [who it's for, what they should feel or do]
Content: [the words/facts/links to include — or "draft it and
I'll edit"]
Taste: [tone + colors + one thing you admire, e.g. "clean like
a gallery site, deep green and cream"]
Boundaries: [e.g. "don't change the other pages" / "ask me
before publishing anything"]

I don't write code. Explain changes in plain English.

For anything big: ask for the plan first

When the ask is more than a tweak — a new page, a redesign, a reorganization — add one sentence: "Show me a plan before you build anything." Claude lays out what it intends to do in plain terms; you approve, adjust, or redirect before a single file changes. Claude Code even has a formal planning mode for exactly this, but the sentence alone gets you the behavior. It's the cheapest insurance in the entire tool.

Iterate like a director

Your reactions do not need to be technical to be precise. Directors don't operate the camera; they say "warmer," "slower," "again, but with confidence." All of these are real notes I've given, and all of them worked:

• "It feels crowded. Let it breathe."
• "Too corporate. I want it to feel like a well-made book."
• "The blue is fighting the photos — find a quieter color."
• "On my phone the menu is broken. Here's a screenshot."

Screenshots are first-class input. Paste one and point at what bothers you. And when something is right, say so — "the header is perfect now, don't touch it" — so it stays right through later changes.

Make it your translator

Any time the narration drifts into jargon, you're allowed to stop the room: "Explain what you just did like I'm not a programmer." Ask why it chose an approach. Ask what a file is for. Ask what would break if you deleted something. This is how the vocabulary arrives — one honest answer at a time, attached to your own project instead of a textbook.

When it asks permission

Claude Code checks with you before consequential actions: creating or deleting things, publishing, running certain commands. Treat these prompts as one-sentence contracts — read the sentence, and if you don't understand it, ask before approving. "What does this do, and what happens if I say no?" is always a fair question. The Habits & Guardrails chapter has the fuller routine.

A small prompt library

Fill in the brackets. Each of these has earned its place in my own sessions.