What Actually Goes in a Claude Project

When someone new starts at your company, somebody hands them the folder. The company overview. Services and pricing. The customer profiles, the handbook, the note about how you like things written. Nobody re-onboards that person every single morning and then acts surprised when they're useless by Wednesday.

But that's exactly how most people use AI. Every chat is day one. You paste in the company background, explain who your customers are, restate how you like emails written, and then do it all again tomorrow in a fresh chat that remembers none of it.

If you've hit that wall, it's not a sign the tool is limited. It's a sign you've outgrown the single conversation.

A Claude Project fixes it. It's a persistent workspace where the folder is already handed over: your documents, your instructions, your preferences, all sitting there before you type a word. Tell Claude about your business once. Every conversation inside that project starts from that foundation.

The question I get next is always the same one. Fine, but what do I actually put in it?

The four things that go in

• Documents. The reference material a sharp new hire would need. Service descriptions, pricing sheets, your ideal customer profile, case studies, past proposals. Whatever the job touches.
• Instructions. This is where the framework we taught in session 1 stops being something you type and starts being something the project enforces. Give Claude its role, its standing jobs, and your always/never rules. Always rate lead fit against the ICP. Never open an email with "I hope this finds you well." Never promise a price before scope is understood. One of the rules in our live demo was "never use em dashes," which regular readers will recognize as the most reliable AI tell in print.
• Business context. Who your customers are, the problems you solve, what separates you from the seven other firms in the deal. This is the difference between output about a company like yours and output about yours.
• Examples. A few real samples of your writing, so what comes out sounds like you instead of like software.

None of this is exotic. It's the same folder you'd hand the new hire. The work is deciding what's in the folder, and you've already done that work every time you've onboarded someone.

What happens when the folder is in place

At session 2 of our AI for Operators series, we built one of these live so people could watch the before and after. The project was business development for a made-up advisory firm: instructions like the ones above, plus four documents. A company overview, an ICP profile, a pricing overview, and sample outreach emails.

Then I typed a prompt that session 1 would have flunked: "Qualify this inbound lead and draft a response." Four words of instruction, pasted lead, send.

Back came a fit rating of strong with a one-line reason, an assessment against each axis of the ICP, and a draft reply with no filler opener and no overselling, matched to the tone of the sample emails. Then it asked whether I wanted the discovery call prepped once a time was booked. I hadn't mentioned discovery calls. The instructions had.

So we tested that too. New chat, same project: "Prep me for this discovery call," plus the meeting details. Out came three points to raise, two questions to ask, likely objections with suggested responses, and the single outcome to aim for on the call. That structure didn't come from the prompt. It came from the standing jobs we'd written into the project ten minutes earlier.

That's the trade. In session 1, quality lived in how well you wrote each prompt. Put the framework in the project once, and the lazy prompt becomes a good prompt. The four-word ask inherits everything.

The details nobody tells you

A few things from the session Q&A that will save you real frustration.

File formats are not equal. Plain text, markdown, and CSV are the sweet spot; Claude reads them directly with nothing lost. PDFs work fine, and under 100 pages Claude reads both the text and the images in them. Word documents convert as text only, so any diagram or screenshot embedded in one silently disappears. When you can choose, choose text.

Capacity is bigger than you think, with one threshold worth knowing. Our whole demo project used under 1% of the available room, and there's no cap on file count. But once a project passes roughly 150,000 words, Claude switches from reading everything at once to searching for relevant chunks. It still works, and the ceiling after that is enormous. The retrieval just gets less thorough than full reading.

Here's the tension in that: you can throw tons of material into a project, and you shouldn't. Both are true. A curated folder that covers one job well beats an exhaustive one that buries the signal, the same way a focused onboarding packet beats forwarding the new hire your entire drive.

Which is why the best advice from the session is also the least dramatic: start small. Build the project around one use case. Add the documents that serve that job, run it for a week, and grow it from there. And when your pricing changes next quarter, swap the document. Projects are living things; they evolve with the business.

Build one this week

Your homework is the same one we gave the cohort: pick one recurring task, build one project around it, and run it a few times. Lead qualification, vendor management, meeting prep, the weekly report you dread. Anything you do repeatedly with the same context.

And the offer we made the cohort stands for readers too. If you build your first project and want a second set of eyes on it, or you're staring at your business unsure which task to start with, we'll take a look and tell you what we see. No charge, no pitch. Grab time with us here.

The folder takes an afternoon to write. You only have to write it once.