The 2-Hour Claude Setup That Made Everything Click

A vendor product changes faster than a codebase. Where a number would age badly, I link the page that holds the current one instead of printing it here.

I wrote a LinkedIn post last Monday in six minutes. It used to take forty.

Nothing got smarter. I stopped opening a blank chat and re-explaining who I am, what I am building, what I sound like and which words I will not use. I wrote that down once, in files, and the chat starts from there.

The setup is not a prompt library. It is a set of files that answer, once, the questions you were re-answering in every chat.

Is this about Claude Projects or Claude Code?

Projects. They are different products and the setup below does not transfer.

Claude Code is a coding agent that runs in your terminal and your editor, reads your repository, and edits files. Its configuration lives in CLAUDE.md and skill files inside the repo.

Projects are workspaces on claude.ai. Each one holds its own instructions and its own uploaded files, and every chat inside it starts with all of them loaded. That is what this post configures. If you came here for the terminal tool, this is not the post you want.

What does the two hours actually consist of?

Seven steps. Each one produces a file or a setting, and none of them is prompting.

#	Step	Minutes	What it produces
1	Create the Project	5	One workspace, named after one recurring task
2	Interview yourself	30	about-me.md
3	Extract your voice	20	my-voice.md
4	Write the anti-AI rules	10	A banned-word and banned-pattern list
5	Write the Project instructions	15	The standing system prompt
6	Add three templates	20	Your best real example of each format
7	Upload the project's real context	15	Analytics, numbers, the messy reality

That is 115 minutes. The two hours in the title is not a round-up for effect, which I only noticed while adding this table.

Why does a Project beat a good prompt?

Because the prompt has to be retyped and the Project does not. Three things make the difference.

Separate workspaces keep contexts from bleeding. A newsletter Project and a client-email Project do not share files, so neither inherits the other's tone.

Instruction adherence is the part I actually evaluate. If I write "never use the word leverage" and the model uses it anyway, the rules file is decoration. That is the test I would run before committing two hours to any tool, rather than taking anyone's word for which one holds up.

File memory removes the re-upload. Drop a folder of documents into a Project and every reply is written with them in scope.

Projects need a paid plan. The current figure is on the pricing page, and I am deliberately not printing a number here that will be wrong by the time you read it.

How do you write the about-me file without writing it?

Get interviewed. Writing about yourself in the abstract produces a CV. Being asked one question at a time produces the messy detail that is actually useful.

Open a chat in the Project and ask for a 30-minute interview, one question at a time, going deep before moving on. Cover who you are, what you are building now, your goals for the next twelve months, what you are afraid of, what you already tried that failed, who your audience is, what they are sceptical of, and what is off-limits in public.

One instruction matters more than the rest: never invent facts about me, only use what I tell you.

Answer as what is true, not as what you wish were true. A model working from your aspirational bio writes copy that sounds like someone else.

How do you capture a voice you cannot describe?

By handing over work instead of adjectives. Paste in three things you wrote that sounded most like you and that landed with real people. A post that worked. An email to a friend. A caption that got a real reply.

Then ask for analysis rather than praise: what you would never say, what you reach for when you are excited, what changes when you are admitting a failure, whether you use emoji, your sentence-length pattern.

The follow-up questions are where the file gets sharp. Words you hate. Phrases you refuse. The adjective you would never pick. Those are the things three samples cannot show and you can answer in a minute.

What do the anti-AI writing rules actually stop?

The tics. Every model has a house style, and it leaks into your drafts unless you name the pattern and ban it.

Pattern to ban	Why it shows up
"Not just X, but Y"	A formula that fills space and asserts nothing
Em dashes everywhere	The default rhythm, and a visible tell
Abstract verbs: navigate, unlock, leverage, delve	Sound technical, carry no meaning
Rule-of-three lists	Ideas forced into threes whether or not there are three
Title Case Headings	A house convention, not yours

Build this file from your own drafts rather than from a list someone else wrote. Read three pieces the model produced for you, mark every phrase that made you wince, and that is the file. It takes ten minutes and it is the single highest-yield item on the list.

What goes in the Project instructions?

Standing rules, not a task. This field runs before every chat in the Project, so it should hold only what is true every time.

Write it as a job description for someone who needs to know your standards: what you want, what you never want, how output should be formatted, and what context to always assume. The same discipline applies as to a system prompt in code, which I wrote about in building production AI agents that actually work: short, role-based, and specific about the failure you are preventing.

Add one line at the top that states your goal for the year. A number, not a mood.

Without a stated goal, "is this good?" is a question about taste. With one, it is a question about fit, and the model can answer it.

Why must templates live in the matching Project?

Because context that does not apply is noise, and noise costs you the thing you came for. A pitch-email template sitting in your newsletter Project pulls drafts toward a register you did not ask for.

Project	What belongs in it
The format's best real example	One template file per format you write often
Performance data	Analytics export, a CSV of recent work and how it did
Proven work	Three to five pieces that actually landed
The goal line	One number, at the top of the instructions

That last row is the step most people skip. Uploading your real numbers is what turns "should I post this?" from a guess into a comparison against your own baseline.

What does the prompt actually look like afterwards?

Twelve words. "Write a LinkedIn post about yesterday's podcast" is enough, because voice, audience, format, banned words and call-to-action style are already loaded.

Measure	Before the setup	After
Prompt length	~800 words	~12 words
Time to a usable LinkedIn post	40 minutes	6 minutes
Context re-explained per chat	Every time	Never

Shorter prompts are also cheaper, which matters at volume rather than at this scale. The general version of that argument, with measured numbers behind it, is in cutting LLM API costs 60%.

What is the step that actually compounds?

Closing the feedback loop. Everything above gets you a workspace that knows you as of today. It does not get better unless your corrections find their way back into the files.

Where feedback happens	Reaches the model?
You rewrite a draft and say nothing	No. The same mistake returns next week
You rewrite it and say what you changed and why	Yes, if you add it to the rules or voice file
A written thread where you reacted to work	Yes, if you paste it in
A phone call	No. Lost unless somebody writes it down
A recorded meeting, transcribed	Yes. Granola, Otter and Wispr Flow all produce a transcript you can drop in

The habit is small and easy to skip: when you edit something, say what you cut and why. "I removed the second paragraph, it read as motivational. I rewrote the close, it had no call to action." Two sentences, once, instead of the same edit every week.

The setup stops being a shortcut and starts compounding at the moment your corrections go back into the files rather than into a draft you silently fixed.

I run the same pattern on this site in code rather than in a chat, described in how I built an AI agent for my portfolio. The mechanism differs. The principle does not.

What does this setup not fix?

Four things, and knowing them in advance saves you the disappointment.

It does not	Why
Decide what is worth saying	The files describe how you sound, not what you think
Make a weak idea publishable	A clear draft of a thin argument is still thin
Remove the review step	You are still the last reader before anything ships
Stay accurate on its own	Files go stale. Goals change, audiences change, the numbers move

That third row is the one I hold on to in client work too. The human stays in the loop for the same reason a regulated system keeps one, which I wrote about in what actually works in enterprise banking: the value is in the draft, and the accountability stays with a person.

Where should you start?

With the one thing you write every week and resent writing. Build that Project, in that order, and stop.

The failure mode is building seven Projects on a Saturday and using none of them. One Project, used daily for a fortnight, teaches you what belongs in the files. Seven Projects teach you nothing, because you never find out which context was doing the work.

Two hours is the whole investment. The question is not whether it works. It is which week you actually spend them.

Checked on 2026-09-21

• Step times as published, summing to 115 minutes
• Prompt length and drafting times as published: 800 words to 12, 40 minutes to 6
• Pricing linked rather than quoted, because a figure printed here will age
• Granola, Otter and Wispr Flow all resolve and all produce transcripts
• Claude Code and Claude Projects are separate products; this post configures Projects

Questions: @bayyash