The most valuable thing you will write in this entire course is a single paragraph. It is the one Claude Code will read at the start of every session for the rest of the project. It is the one you will paste at the top of your CLAUDE.md file in the next phase. It is the one you will read back to yourself when the build gets messy and you have forgotten why you started.
This lesson is the one where you write that paragraph. If you finish this lesson, you are more than halfway through the Define phase — because everything after this is a refinement of the paragraph you write here.
What a good brief sounds like
Before we write yours, here are three that work. Read them out loud. Notice the rhythm — short sentences, concrete nouns, no jargon.
Tool example:
A private weekly check-in page just for me. Every Sunday evening I open it and fill in five questions — how I slept, how I ate, what I made, what I read, what I want more of next week. It saves my answers and shows me the last eight weeks so I can see trends. It lives on my laptop and nobody else ever sees it. No login, no cloud, no sharing. The whole point is that it is mine.
Showcase example:
A single-page website about the twelve books that changed how I see work. Each book gets a short note — two or three sentences, personal — and a picture of the cover. The design is quiet and serif, like a reading room. There is one link at the bottom that goes to my email. The site is called Books That Made Me and lives on booksthat.me. It exists so that when someone asks what I read, I can send one link instead of twelve emails.
Product example:
A booking page for my sister Ellie’s hair salon. Clients pick a service (cut, colour, or both), pick a day and a time from Ellie’s calendar, and get a confirmation. Ellie sees the bookings in her phone. The page looks like her — warm, a bit playful, no stock photos. It replaces the current DM chaos on her Instagram. Three users (Ellie and her two part-timers) plus however many clients want to book.
Each one tells you, in about sixty seconds of reading:
- What the thing is.
- Who it is for.
- What is in it.
- What is explicitly not in it.
- How it feels.
That is the whole job of the brief. Nothing else.
What a bad brief sounds like
For contrast, here is a bad one. This is the kind of brief people write when they are trying to sound like they know what they are doing.
A modern, responsive web platform leveraging AI to deliver personalised book recommendations via an intuitive interface, with user authentication, a recommendation engine, favouriting, social sharing, and analytics dashboards. MVP will include core features with a roadmap for expansion.
Read it twice. Can you picture the site? No. Who is it for? Unknown. How does it feel? Unknown. What is in v1? The word “core” is doing all the work. This brief cannot be built because it does not say what the thing is — it says a category the thing vaguely belongs to. A category is not a project.
Good briefs are specific enough that a friend can picture the site after hearing it once. Bad briefs are general enough that anyone could build anything from them.
Writing yours
Open Claude Code. Start a session in an empty folder (or reuse the one from earlier Define lessons). Paste this prompt, filling in the bracketed parts from the previous two lessons:
I am writing the one-paragraph brief for my project. Here is what I have so far. Bucket: [tool / showcase / product]. Rough idea: [one sentence]. Constraints: I have [X hours] a week, the audience is [who], it [does/does not] need to keep working after the initial build, and I can spend [budget]. I already have [list]. Based on this, write me a draft one-paragraph brief. It should be one short paragraph — five to seven sentences. It should answer: what the thing is, who it is for, what is in it, what is explicitly not in it, and how it feels. Do not use jargon. Do not use the word “platform.” Do not hedge. Write it the way I would describe the project to a friend at a dinner party.
Claude will give you a draft. It will be pretty good. It will also be wrong in some small way — the tone, a feature you do not want, a phrase that feels generic. That is expected. Drafts are always a little off.
The three rewrites
Here is the technique that turns an okay draft into a great brief. Do it three times, each time with a specific instruction.
Rewrite 1 — cut. Tell Claude:
That is a good draft. Now cut everything that is not essential. The brief should be shorter. Remove any sentence that would not change what I build if it were deleted. Show me the shorter version.
You will be surprised how much comes out. The first draft always has hedging, redundancy, and context that is not actually about the project. The shorter version is clearer.
Rewrite 2 — personalise. Tell Claude:
Now rewrite it in a voice that sounds like me. Not corporate. Not neutral. I am going to read this out loud. It should sound like something I would actually say. Here is an example of how I write or speak: [paste a short sample of your writing — a tweet, a paragraph from an email, anything].
The personalised version is the one that will survive. A brief in your own voice is one you will actually use. A brief in a generic voice gets abandoned because it feels like someone else’s project.
Rewrite 3 — test the reader. Tell Claude:
Now pretend you are a friend of mine who knows nothing about this project. Read the brief. Tell me what you picture the project looks like, who it is for, what is in it, and what is not in it. Be specific.
If Claude’s description matches what you intended, the brief works. If it does not, edit the brief to fix the gap and run this test again. Do this until the brief “reads” correctly — a stranger could understand the whole project from one paragraph.
Save it
When the brief is right, save it in a file called brief.md in the same folder you have been working in. Claude Code can do this for you:
Save the final version of the brief in a file called brief.md in this folder. This is going to become the source of truth for the whole build.
You now have a file you will keep referring to. In the next phase — Shape — this brief becomes the seed of your CLAUDE.md. Everything the AI knows about your project starts from this paragraph.
Read it back, out loud, to yourself
Before you move on, do one small thing. Read the brief out loud, to yourself, slowly, in your own voice. Not in your head — actually out loud.
If it sounds right, good. Continue.
If anywhere in it you feel a little embarrassed — a place where the language is too corporate, or too vague, or not quite what you meant — stop and rewrite that line. Small discomforts are signals. They get louder as the project goes on, and by the end of Build you will hate the whole brief because of a phrase you disliked at the start. Fix it now while the document is small.
Mission checkpoint
Third chapter of Mission 1: Your Brief. One more lesson in Define, and then the mission is complete — you move into Shape and your brief becomes the heart of your CLAUDE.md.