Your brief is too big.

I have not read it and I am telling you it is too big. I am telling you because every first brief is too big. The constraints phase made it smaller. The one-paragraph lesson made it sharper. But you still, right now, have more in it than you can actually finish. That is not a failure — that is the shape of first drafts.

This final Define lesson is about cutting it down. Not to punish the idea. To find the real project hiding inside the big one.

Why first briefs are always too big

When you describe a project, you describe the version in your head — the complete one, the one that feels like a real thing. That version has everything: the features, the pages, the polish, the social proof, the edge cases, the nice-to-haves. It lives in your head fully formed because you have been thinking about it for a while, and brains do not count hours.

Hands count hours. Hands build one screen at a time, one feature at a time, one file at a time. And a brain can picture a year of work in ten seconds, but hands cannot do a year of work in less than a year.

The gap between what the brain pictures and what the hands can finish is where abandoned projects come from. Cutting is the thing that closes the gap before you start. It is cheaper to cut an idea than to build it and leave it unfinished.

The adversary prompt

The trick to cutting well is to not do it yourself. You are emotionally attached to the big version — you wrote it, it feels like your project, you do not want to lose pieces of it. Someone else needs to make the case for a smaller version, and then you can push back on the pieces you genuinely want to keep.

Claude Code can play that someone else. Open your project folder with the brief.md file in it. Open a brand-new chat — not the same conversation you have been using. You want Claude to come at your brief with fresh eyes, not remember all your earlier back-and-forth. Paste this:

Here is my project brief:

[paste your entire one-paragraph brief]

I want you to play the role of a sceptical friend who has seen a lot of projects started and not finished. Your job is to argue that this brief is too big for a first version, and to propose a smaller version that I could actually finish. Be specific. Name the features that should be cut from v1 and put into a “v2 or never” list. Name one or two things I should double down on — the core of the project, the reason it exists, the thing that would make it worth building even if everything else was stripped away. Do not be polite. Do not hedge. Argue the case for a smaller, braver version.

Claude will come back with a critique. It will pick at things. It will propose cuts. Some of them will feel right and some will feel wrong. That is the whole point — the wrong-feeling ones are where the real project is hiding.

Defending and cutting

Read the critique. For each proposed cut, do one of three things:

Accept it. The feature was not essential. You had it in the brief because it felt comprehensive, not because it mattered. Cut it. Put it on a v2-or-never.md file in your project. Move on.

Defend it, but with a reason. Tell Claude why the feature is core and let Claude argue back. The feature has to survive an exchange — not “I want it” but “without this, the project does not make sense because of [specific reason].” If you can defend it in one sentence, it stays. If you find yourself using the words “also” or “plus it would be cool if,” it was not core, and you are trying to keep it for the wrong reasons.

Transform it. Sometimes a feature is core in spirit but bloated in execution. “User accounts” is too big for v1; “saving a draft to the browser” might cover the same need at one-tenth the complexity. “A whole stats page” is too big for v1; “a count of how many people visited this week” might cover the same need at one-tenth the complexity. Ask Claude: “Is there a simpler version of this feature that keeps the intent but costs half the work?” Usually there is.

Go through every feature in your brief this way. Accept, defend, or transform. Keep going until the brief you are holding is the one that matches what Claude said “you could actually finish.”

The one-feature rule for first projects

Here is a rule that is nearly always right: your v1 should have one feature. Not one screen — one feature. The thing that makes the project interesting.

A workout tracker has one feature: logging a workout. Everything else (seeing history, weekly summary, goal tracking) is v2.

A portfolio has one feature: showing your work. Everything else (contact form, about page, blog) is v2.

A booking page has one feature: booking. Everything else (profile, preferences, notifications) is v2.

Your v1 might look like it is doing two or three things when you describe it, but if you break it down, almost always one thing is the reason the project exists and the rest is scaffolding. Cut the scaffolding. Ship the reason. Come back for the scaffolding after people are using the reason.

Tell Claude:

Based on the brief, what is the single most important thing the project does? The one thing that, if everything else was removed, would still be worth building. Name it in one sentence, then rewrite my brief around that one thing as the core, with everything else treated as v2.

The new brief — the one that is about one thing, done well — is the one you are going to hand to Claude in the Shape phase, starting with turning your brief into a CLAUDE.md. The same “cut harder” muscle comes back later in Knowing When to Stop.

What about the stuff you cut

Put it in a v2-or-never.md file alongside your brief. Write each cut feature as one line. Do not elaborate. The list is not a promise — it is a graveyard you can resurrect things from if v1 works and you still care.

v2-or-never
-----------
User accounts with password reset
Exporting entries to PDF
A weekly email summary
Dark mode toggle
The landing page with the big hero image

Most of the list will never come back. A few things might. None of them will hurt you by being in a file instead of in the project. The worst outcome of a cut feature is “I will add it later.” The worst outcome of an uncut feature is “I never finished the project.” The first is almost free; the second is expensive. Cut.

When Mission 1 is done

You should now have:

  • A brief.md with your post-cut, post-adversary brief. One paragraph, one core feature, short enough to read in thirty seconds.
  • A v2-or-never.md with everything that did not make it into v1.
  • A slight relief that the project feels smaller and more possible than it did an hour ago.

That last feeling is the goal. If you feel relief and a little excitement instead of the vague dread of something too big — the mission worked. If you still feel dread, run the adversary prompt again. Cut more. You will not regret it.

Mission checkpoint

This completes Mission 1: Your Brief. You have done the hardest part of the entire Path — you picked a thing to build, figured out what you can finish, and wrote it down in one paragraph.

Open your profile and mark Mission 1 complete. One more chapter rounds out Define — Reverse Prompting, where Claude asks the questions instead of you. It is a technique you will reach for in every phase from here.

After that, Shape begins. The brief you just wrote becomes a CLAUDE.md: the memory file that lets Claude Code hold your whole project in its head, every session, for as long as the project exists.