Claude Projects for Work: How to Set One Up So Claude Already Knows Your Job

Every time you open a new chat, Claude meets you for the first time. It does not know who you report to, which Thursday meeting is the one where decisions actually get made, or that the supplier who has gone quiet has done this twice before. So you explain, again, and because explaining takes longer than doing the job yourself, you stop asking. Using Claude Projects for work is how you stop explaining. Set one up properly and every chat inside it starts already knowing who is asking.

That is a context problem, not a clever-model problem. The same tool gives you a generic list about "blocking focus time" or a specific answer about protecting Tuesday morning for the paperwork that is due before Thursday. The only difference is what it was told before you asked.

01 / What a Claude Project actually is

A Project is a workspace inside Claude with three things that ordinary chats do not have. It has its own instructions, which Claude applies to every chat you start inside it. It has its own knowledge, a set of files you upload once and that every chat in the project can draw on. And it has its own chat history, kept together rather than scattered through your sidebar.

According to Anthropic's help centre, Projects are available on every plan, including free accounts, though free users can create a maximum of five. On paid plans, when your project knowledge gets close to the limit of what Claude can hold at once, it switches to a retrieval mode that searches your files for the relevant parts instead of loading everything, which Anthropic says expands capacity by up to ten times. Free accounts do not get that. On Team and Enterprise plans you can also share a project with colleagues, with view or edit permissions.

Two details people miss. First, the project name and description are for you: Claude cannot see them, so anything it needs to know goes in the instructions or the files. Second, memory. Where memory is switched on, each project has its own memory, kept separate from your other chats. That is useful, but it is not the mechanism. Anthropic is clear that context is not shared across chats in a project unless you add it to the project knowledge. If something matters, write it down where it will load every time.

02 / The instructions are your Chief of Staff Brief

The instructions box is the most valuable piece of real estate in the whole setup, and most people either leave it empty or write "You are a helpful assistant who is concise". That tells Claude nothing about you.

In AI Powered Chief of Staff the instructions have a name: your Chief of Staff Brief. It is one document describing who you are, what you are accountable for, the people around you and how you write. Written once, loaded every time. I spent fifteen years running CEO offices, and the thing that made a chief of staff useful was never that they were clever. It was that they knew the context: who the boss is, which meetings are political, how a bad update should be delivered, what "handle it" actually means.

Start with three sections:

• Who I am. What you are actually accountable for, which is rarely your job title. What is yours to decide and what needs someone else's yes. What you are quietly bad at, so it knows when to nudge you. The test: could someone read this and predict what lands on your desk on a bad Tuesday?

• My working world. Who you report to and what they care about, who depends on you, the external people who can eat a day of your time, your recurring commitments and where your work actually lives (calendar, email, task tracker, documents).

• How I communicate. How you write, how it changes depending on who is reading, and the things you never do. The never list is more useful than the always list.

Here is a compressed version of what one looks like in the instructions box, for an invented Head of Operations:

MY CHIEF OF STAFF BRIEF I'm Head of Operations at a 60-person company. I report to the COO. My priority: the supplier migration recommendation, due before Thursday's leadership meeting. Protect my Tuesday 09:00 to 12:00 focus time and Maya's 14:00 one-to-one. I recommend; the COO approves spend; Technology signs off. Lead with decisions, trade-offs and next actions. Separate what you read from what you inferred, and name what is missing rather than filling the gap. Draft only: never send, spend or change my calendar without my approval.

That middle instruction about separating fact from inference earns its place. A tool that blends evidence and guesswork into one confident paragraph is how you end up repeating something to your director that was never true.

03 / Do not write the instructions yourself. Get interviewed.

If you sit down to write your Brief from a blank page, you will produce something that sounds like a LinkedIn profile. Instead, open a chat in the project, turn on voice input and let Claude interview you:

I'm building a permanent context document about myself so you can act as my chief of staff. Interview me. Ask one question at a time, start broad and go narrower. Push back when I describe my job in job-description language rather than what actually happens. Cover what I'm accountable for, the people around me, how I communicate and where my work is stored. Ask at least twenty questions before you write anything. Don't give advice yet.

Answer out loud. Typing makes people careful, and careful is the enemy here. Speaking gets you the honest version: the colleague who never replies, the meeting you resent, the part of the job you avoid. That is exactly the material that makes the instructions better than a job description.

When it hands you the draft, do not accept it. Ask: "Where in this have you flattered me, smoothed something over or made me sound more organised than I described? Rewrite those parts in plainer language." A Brief that describes an idealised version of you produces advice for a person who does not exist. Then paste the result into the project instructions and save.

04 / What to upload to project knowledge

Instructions describe you. Files show Claude the evidence. The rule is simple: give it the original, not your summary of it. Your summary has already thrown away the detail that would have made the answer useful.

Good first uploads for a work project:

• Your org chart, or a plain list of who is around you

• Your objectives for the year, or your last review

• A screenshot of a normal week in your calendar

• Eight to ten messages you have actually sent: at least one upward, one sideways and one to your team

That last one does more for drafting than any description of your tone ever will. Nothing teaches voice faster than real examples.

What stays out matters just as much. Start with what your employer allows, because some organisations have an approved tool and a written policy, and silence is not the same as permission. Whatever the policy, keep out employee records and salary information, anything under NDA that is not yours to share, market-sensitive board papers, anything a client told you in confidence, identity documents and medical information. You can usually still get the work done by redacting names and pasting the structure. One rule covers most of it: if you would not forward it to a colleague in another department, do not upload it.

05 / One project for your whole working life, or one per area?

Start with one. A single project that holds your working life, with your Brief in the instructions and your core files in knowledge, is the right default. Every workflow you build later (a daily brief, meeting prep, a weekly review) can live in that same project and read the same Brief, which is why none of them sound generic.

"Working life" should also mean the whole of it. The school appointment, the train you cannot miss and the present you need before Saturday belong in there alongside the board papers, because that is how your week actually works. A tool that only knows your work diary will confidently tell you to protect the exact hour you are collecting someone.

Split into separate projects when you genuinely have separate lives with separate rules. A job and a side business get a project each. So do two clients. Mixing them produces advice that is confused about which life you are in, and it is also how one client's details end up in another client's draft. A very large piece of work can justify its own project too, but for most projects it is cleaner to keep the records as files in your main one.

06 / Mistakes that make Claude Projects feel generic

Leaving the Brief in a chat. The interview happens in a conversation, and conversations end. If the finished Brief is not in the project instructions, you have done the work for nothing. Check it is there.

Relying on memory instead of instructions. Memory is a bonus, not the foundation. It is inferred, it is patchy, and it can be switched off. The instructions load every time.

Describing your job like the job description. The first draft almost always does this. Rewrite it to describe what actually lands on you, including the things nobody officially gave you.

Never updating it. Your manager changes, a project ends, a new one arrives. Tell Claude "update my Brief: I now report to Sam, not Priya", let it hand back the revised version and paste it over the old one. Put a date on it so you know whether it describes your current job or your last one.

Not testing it. Ask three questions you already know the answer to. What is most likely to go wrong in my week? Draft a short message telling my manager something will be late. What do you still not know about me that would make you more useful? If it says it has everything it needs, your Brief is too thin to know what is missing.

What good looks like

You ask what you should focus on tomorrow, and the answer is about your week rather than everyone's. It knows the decision that has to reach the COO before Thursday and notices that a one-to-one has moved twice. Same tool as before. It just knows who is asking.