The setup that runs in the background.
Unit 3 of the main course taught you why Projects matter. This module teaches you how to build them — every setting, every gotcha, every best practice that working professionals figure out the hard way over months.
If you've already built a Project or two, you've probably noticed something. The first one was magical. The third one started to feel cluttered. The fifth one had files you couldn't remember loading and instructions that mostly contradicted each other. By the tenth, you stopped trusting your own setup.
That progression is normal. It's also avoidable. The professionals who get long-term value out of Projects — who run twenty active Projects across years without the whole system rotting — follow a small set of disciplines. This module teaches those disciplines.
What you'll walk out with
A clear mental model of what Projects are and aren't. A file-loading discipline that keeps signal high. The layering rule for Custom Instructions vs Project Instructions. A naming convention that scales. Two end-to-end walkthroughs you can copy. And a quarterly audit routine that keeps your setup from rotting.
What this module covers
- What Projects actually are — and the three things people mistake them for
- The file-loading discipline — curation principles that beat thoroughness
- The instruction layering rule — what goes in Custom Instructions vs the Project itself
- Naming and organizing at scale — the convention that survives 20+ Projects
- Two walkthroughs — Customer Success Project, Content Marketing Project, end-to-end
- The quarterly audit — the 30-minute routine that prevents Project rot
What Projects actually are.
A Project is a workspace, not a folder. That sentence sounds like semantics. It changes how you use the feature.
The folder mental model is what most professionals start with. Files go in, conversations come out, the Project is the box that holds them. This mental model is wrong in a small but consequential way: it treats files as the primary content and conversations as transient. In practice, the opposite is closer to true.
The workspace mental model: a Project is a configured environment in which Claude operates. The files are reference material the environment leans on. The instructions are how the environment behaves. The conversations are the work happening inside the environment. Move from one Project to another and you've changed environments — same Claude, different operating context.
The three layers of every Project
Files
Documents Claude reads as needed. Brand guides, past examples, reference policies, data summaries. Files are the slowest-changing layer — once loaded, they typically sit there for weeks or months.
Instructions
The standing brief for this Project. Who Claude should be, what tone to use, what sourcing rules to follow, what to never do. Instructions are the medium-changing layer — you'll refine them over weeks as you learn what works.
Conversations
Each individual chat happening inside the Project. The actual work. Conversations are the fastest-changing layer — they come and go daily, hourly. Each one inherits files and instructions, but produces something specific.
Three things Projects are NOT
Not a substitute for a wiki
If you're loading 50 documents because "Claude should know about everything," you're using a Project as institutional memory. It's the wrong tool. Use a real document store; load only the high-signal subset into the Project.
Not a sharing mechanism
You can share Projects with teammates, but a Project is not a publishing surface. It's a working environment. If you want to publish content, that's a different tool. If you want collaborators to work alongside you, that's a use case Projects support directly.
Not a magic productivity layer
A Project doesn't make Claude smarter. It makes Claude more relevant to you. The same Claude with the same prompt produces a different answer inside a well-configured Project than outside one. Less variance, more on-target output.
The mental shift in one sentence
A Project is the environment Claude works in. Files are what's on the shelf, instructions are how it behaves, conversations are the work. Move that mental model into place and the rest of this module makes sense.
The file-loading discipline.
The single biggest determinant of whether a Project ages well is what you do (and don't) put in it. Most professionals over-load. The fix is a small, ruthless set of curation rules.
The 3-to-5 rule
If you're loading more than five reference files into a single Project, you should probably have two Projects. The number isn't sacred — sometimes seven is right, sometimes three is plenty — but the pattern is: fewer high-signal documents almost always beat more mediocre ones.
Why? Because Claude retrieves the most-relevant content from your Project files each time it answers. If your files contradict each other (because they're from different time periods, different teams, or different contexts), Claude's output gets noisier. If your files are highly aligned, the output stays sharp.
The "sharp new hire" filter
Before you load a document into a Project, ask: "If a sharp new hire could only read this many documents to understand this domain, would this one make the cut?"
Most documents fail this test. The decade-old strategy memo. The deck from the workshop you ran in 2022. The CRM dump with 14,000 lines. Those documents have value somewhere — but not as foundational context for a Project that's supposed to behave like a sharp colleague.
What to load (with examples)
Examples of the work itself
Past pieces that represent the standard. Three to five exemplars of "good." Claude pattern-matches to these heavily — it's the most efficient way to teach voice without writing 800 words of instructions.
Reference data that doesn't change often
Current org chart. Customer segments. Pricing tiers. Product feature matrix. Brand guide. Things that are stable and authoritative.
A short context document you write yourself
One page. Who this Project is for, who the audience is, what the standards are, what's off-limits. This document is the highest-leverage thing in most Projects because you wrote it specifically for this Project.
What to NEVER load
- Draft documents — anything labeled "draft," "WIP," or "v1." Claude can't distinguish drafts from approved versions.
- Documents that contradict your current direction — the strategy from 2 years ago, the failed campaign, the deprecated process. They'll pollute output.
- Confidential personnel material — anything involving specific people, compensation, performance reviews, hiring discussions. Wrong tool, wrong context.
- Massive data dumps — CSVs with thousands of rows, full email archives, complete chat histories. Claude will use them, but the signal-to-noise ratio collapses.
- Anything you'd be uncomfortable showing a contractor — Projects can be shared, codes can leak, the security model is "trust the boundary." Don't put things in that you'd regret if the boundary moved.
Reflection · 3 minutes
If you currently have any Projects, name one and list every file in it. For each file, ask: "Would a sharp new hire need to read this?" Cross out the ones that don't pass the test.
Custom Instructions vs Project Instructions.
Both fields exist. Both shape Claude's behavior. They are not interchangeable. Getting the layering wrong is the second most common Project mistake.
The rule
Universal stuff in Custom Instructions. Domain stuff in Project Instructions.
If a rule applies to everything you do with Claude — your identity, your writing voice, things you never do — it belongs in Custom Instructions. If a rule applies only to this Project's domain — the customer profile, the brand voice for this product, the audience for this deliverable — it belongs in Project Instructions.
What goes in Custom Instructions
- Your identity — what you do, who you work with, what industry
- Your voice rules — active vs passive, paragraph length, banned phrases
- Format defaults — bullets vs prose for analysis, length norms
- Universal "never do" rules — the corporate clichés you refuse, the punctuation rules you hold across all work
What goes in Project Instructions
- Who Claude should be in this Project — "you are our customer success voice" vs "you are our board-facing voice"
- The audience profile for this Project's outputs
- The standards for this specific kind of work — "always cite the policy section" for an HR Project, "always show the calculation" for a finance Project
- Project-specific never-do rules — things that matter here but not elsewhere
The diagnostic question
When you're deciding where to put a rule, ask: "Would I want this rule applied if I opened a completely different Project?"
- If yes — it goes in Custom Instructions
- If no — it goes in Project Instructions
The kitchen-sink mistake
The most common failure mode: dumping everything into Custom Instructions because you only have to write it once. The result: rules from your HR work bleed into your customer success work, rules from your marketing voice bleed into your board memos. Output quality wobbles for reasons that are hard to diagnose.
Keep Custom Instructions universal. Resist the temptation to add domain-specific rules at the global level. Future-you will thank you.
The layering example
Custom Instructions
"I'm head of marketing for a fintech startup. Write in active voice, short paragraphs, plain English. Never use 'leverage,' 'synergy,' or 'unlock.' Default to bullets for analysis, prose for client-facing work."
Project Instructions (Investor Updates)
"You're drafting weekly investor updates from the CEO. Audience is seed investors who are sharp and busy. Lead with the headline number, then the most important development of the week, then any specific ask. Numbers as raw figures with one-line context. No spin on bad weeks."
The Custom Instructions handle voice. The Project Instructions handle context. Together they produce output that sounds like you AND knows what this specific work is about.
Naming and organizing Projects when you have twenty.
If you only have two or three Projects, naming doesn't matter much. The moment you hit ten, naming is the difference between "I open Claude and immediately know which Project to enter" and "I waste 90 seconds every time finding the right one."
The naming convention that scales
Use the format: [Category] · [Specific deliverable or domain]
Examples
Sales · Renewal BriefsSales · Discovery Call PrepMarketing · Investor UpdatesMarketing · Customer NewsletterOps · Monthly CloseOps · Vendor ReviewsPersonal · Reading Notes
The category prefix lets your eye scan a long list and group instantly. The specific deliverable tells you what work happens in this Project. The convention also reveals when you should split a Project — if you can't write a single specific deliverable name, the Project is probably trying to do too much.
The "split" signal
If you find yourself writing a Project name like Marketing · All campaign work — split it. The "all" is doing too much work. Marketing · Email Campaigns and Marketing · Social Campaigns are two cleaner Projects.
The five-Project starter pack
Most professionals shouldn't have more than five Projects in their first year. Resist the temptation to create a Project for every task — most tasks are one-offs or fit cleanly into an existing Project's scope.
Five Projects that cover most working professionals' work:
- One for your recurring high-stakes deliverable (board memo, weekly report, monthly review)
- One for your customer/audience-facing communication (sales emails, support replies, newsletter)
- One for your internal/team communication (Slack updates, internal memos, standup notes)
- One for your domain-specific analysis (the kind of analytical work specific to your role)
- One personal/learning Project (reading notes, life logistics, side projects)
The "retire vs delete" rule
When a Project goes stale — you stop using it for six weeks — don't delete it immediately. Add [Archive] to the name and leave it for one more month. Half the time you come back. The other half, you confirm it's actually dead and delete cleanly.
The naming discipline pays compound interest
Working professionals with disciplined Project naming routinely run 10–20 active Projects without confusion. Working professionals who name lazily run 4 Projects and stop adding more because the cognitive cost of finding the right one outweighs the value of a new one. Naming determines how many Projects you can actually operate.
Build a Customer Success Project from zero.
Step-by-step. Pretend you're a CSM at a mid-market B2B SaaS company. Twenty minutes of setup produces a Project that handles 80% of your written customer work for the next year.
Step 1 — Name and scope
Open Claude → New Project. Name it Customer Success · All Communications. The scope: every written customer-facing message except contracts and renewal pricing.
Step 2 — Files to load (5 total)
- Three of your best past customer emails — ones that hit the tone you want. These set the voice better than any instructions can.
- The current product feature matrix — what you have, what's coming. Lets Claude reference accurate capability info.
- A one-page "Customer Success Voice" document — you write this yourself. Audience, tone, common situations, common phrases to use/avoid.
Step 3 — The "Voice" document (write this yourself)
Customer Success Voice — template
AUDIENCE: Customer admins and end users at our mid-market B2B accounts. Usually managers or directors. Sharp but time-pressed. They read on mobile. TONE: Warm but adult. Direct without being curt. Plain English. No corporate language. ALWAYS: Open with their first name on its own line. Reference their specific situation. End with a direct reply path. NEVER: "I hope this finds you well." "Just checking in." "Per my last email." "Synergize." "Leverage." Exclamation points except in genuinely celebratory contexts. LENGTH: Default 80–150 words. Anything longer needs a real reason. ESCALATION: If the customer mentions legal, attorneys, or "considering alternatives" — stop, flag, route to me. Don't draft.
Step 4 — Project Instructions
You are a customer success manager at a mid-market B2B SaaS company. Your audience is customer admins — sharp, busy, mobile-first. Match the voice from the Customer Success Voice document loaded in this Project. Reference the past examples for tone and structure. When the user gives you customer context, draft the email or message they need. Default to the format: opening line acknowledging their situation, the substance (2–3 sentences), the specific next step, sign-off. If the customer's situation hits any escalation criteria, do not draft — stop and flag for the user. When in doubt, lean direct over polite. Adult over performative.
Step 5 — First test conversation
Open a chat in the new Project. Type something like: "Customer is two weeks late paying their annual renewal. Their primary contact has been silent on three follow-ups. Draft a fourth touch — direct, not aggressive, gives them a clear out if they're not renewing."
The output should: open with the customer's first name on its own line, acknowledge the silence directly, offer a graceful path forward (renew, decline, or schedule a quick call), and end with a clear reply path. Under 150 words. Sounds like a senior CSM, not a script.
Step 6 — Refine across the first week
Over the first 5–7 real uses, you'll notice things that need adjusting. The opening line lands too formal. The escalation criteria miss a real case. The closing default needs work. Each refinement goes into the Project Instructions or the Voice document. By the end of week 1, the Project is producing drafts you can send with minimal edits.
The Project compound
The CSM who runs this Project for six months has a setup that produces drafts faster and more consistently than they could write themselves. The CSM who runs it for two years has trained Claude into a model of their best work. That's the asset.
Build a Content Marketing Project from zero.
Different domain, same shape. Notice how the discipline transfers — same five files, same instruction layering, same first-week refinement.
Step 1 — Name and scope
Name: Marketing · Content Production. Scope: blog posts, social posts, email campaigns, ad copy. Excludes brand strategy and creative direction — those belong in a separate Project (or no Project at all, since they're not recurring).
Step 2 — Files to load (5 total)
- Three of your best-performing past pieces — across email, blog, social. Pick by engagement data, not personal preference.
- Your brand voice guide — the formal one if you have it, or a one-page distillation if you don't.
- An audience research summary — top three customer personas, what they care about, what they hate.
Step 3 — Project Instructions
You are a senior content marketer at our company. Your work goes out to our existing customers, our prospects, and our broader industry audience. Match the voice from the brand voice guide loaded in this Project. Reference the past examples — these represent the bar. For every piece of content you produce: lead with what's specifically true for our audience, not what's generally true about the topic. Avoid the "5 tips" / "10 ways" listicle template unless it's clearly the right format. Avoid AI-tells: em-dashes used everywhere, sentences starting with "It's not just X — it's Y," the word "leverage." If the request is for a blog post, default to 800–1200 words. If email, 200–400. If social, follow the platform's natural length. Always ask the user what specific result they're trying to drive with the piece before drafting. Content with no defined success criterion is content nobody reads.
Step 4 — Where this Project's instructions differ from CSM
Notice what changed and what didn't:
- Voice rules stay universal — those live in your Custom Instructions, not duplicated here
- Audience profile changed — customer admins → mixed customers/prospects/industry
- Format defaults changed — 80–150 words → varies by channel
- Project-specific behavior added — "ask what result they want before drafting" is a discipline specific to content work
Step 5 — First test conversation
Try: "Blog post about the difference between AI workflows and AI agents. Audience is technical operators at mid-market companies. Goal is to position our product as the right choice for someone moving from workflows to agents."
Notice the Project responds with a clarifying question first ("What's the specific decision moment you want them to make?") before drafting. That's the instruction working.
Step 6 — The refinement loop
Same as CSM. First 5–7 real uses surface the gaps. Refine the instructions or add a sixth file (maybe an audience-specific terminology cheat sheet) and the Project tightens.
Reflection · 5 minutes
Sketch your own first Project. Name, scope, files (be specific — actual document titles), the one paragraph of Project Instructions you'd start with.
The quarterly audit.
A Project that worked perfectly six months ago can quietly become a Project that produces confidently-wrong output. The audit is what prevents that.
Why Projects rot
Three things happen between you and your Project over time. Your work shifts — different priorities, different customers, different deliverables. Your information shifts — the org chart changes, the pricing matrix updates, the strategy moves. Your standards shift — what was acceptable in Q1 isn't acceptable in Q3.
Meanwhile, your Project sits there. Same files. Same instructions. Same confident output — except now the output is anchored to a world that doesn't quite exist anymore.
The 30-minute quarterly audit
1. The file scan (10 min)
Open each Project. Walk through every file. For each: still accurate? still relevant? still the best example? Replace stale documents. Delete obsolete ones. Don't be precious — if a file is six months old and your work has moved, swap it for something current.
2. The instructions re-read (10 min)
Read every word of the Project's instructions. Anything that no longer matches how you work? Anything that's become a workaround for a problem that doesn't exist anymore? Anything that's missing — a rule you wish was there?
3. The "first output" test (10 min)
Open a new conversation in the Project. Send a standard request — something this Project handles regularly. Read the output critically. Does it still sound like you? Still reflect your current standards? If not, the Project needs work.
What to look for in the audit
- Files that contradict each other — if you have a "Q1 strategy" doc and a "Q3 strategy" doc, drop the Q1 one
- Instructions that contradict themselves — usually accumulated layers from different refinement passes
- Missing escalation criteria — situations the Project handles silently that you'd actually want flagged
- Output drift — answers that are technically right but in a voice that no longer matches
- Obsolete personas — the audience profile that no longer represents your customers
The audit schedule
- Quarterly — every Project gets the 30-minute audit
- After any major change in your work — new role, new market, new product, big strategic shift
- When output starts feeling off — even if you can't say why
The compound effect
Working professionals who run the quarterly audit have Projects that get better every year — sharper, more aligned, more useful. Working professionals who skip it have Projects that get worse every year and don't realize it. Same feature, same effort up front, completely different outcome over time.
Projects module — done.
You have a working mental model, a curation discipline, an instruction layering rule, a naming convention, two walkthroughs, and an audit routine. That's the whole game.
What you walk away with
The mental model.
A Project is a workspace, not a folder. Files are reference. Instructions are behavior. Conversations are the work. Move that model and the rest follows.
Curation beats thoroughness.
3-to-5 high-signal files beat 50 mediocre ones. The "sharp new hire" filter is your test. What you leave out matters as much as what you put in.
Layer instructions deliberately.
Universal in Custom Instructions. Domain in Project Instructions. The diagnostic question: "Would this rule apply in a completely different Project?"
The audit keeps it alive.
Thirty minutes per Project per quarter. Files, instructions, first-output test. Without the audit, every Project eventually rots. With it, every Project gets sharper over time.