Claude Projects for a Marketing Team's Shared Context
What to Put in Project Knowledge, How to Write the Instructions, and How to Keep It From Going Stale
Short answer
A Claude Project gives a marketing team one shared context for every chat. Put the stable material in project knowledge (positioning, voice, ICP, product facts), write instructions that say how to use it, date every file, and keep live data such as competitor moves or campaign numbers out of it, because a pasted snapshot goes stale.
1. What is a Claude Project, and what does it give a marketing team?
A Project is a workspace with its own chats, knowledge files and instructions. For a marketing team it means every chat starts from the same positioning, voice and product facts instead of whatever someone pasted that morning.
- Claude Project
- A self-contained Claude workspace with its own chat history, uploaded knowledge files and project instructions, which Claude applies to every chat started inside it.
As of September 2026, Anthropic describes Projects as self-contained workspaces with their own chat histories and knowledge bases, available on every plan including free accounts, which can create up to five [s1]. On paid plans, a project that approaches its capacity switches to retrieval mode automatically, so it can hold more material than fits in a single context window [s2].
The marketing value is consistency rather than intelligence. When five people each paste their own copy of the value proposition, the model writes five slightly different brands. When the positioning lives once in project knowledge, every draft, brief and rebuttal starts from the same source, and fixing the source fixes every future chat.
2. What should go into project knowledge?
Material that is true for months: positioning, brand voice, ideal customer profiles, the message house, product and pricing facts, and approved proof points. Each file gets an owner and a date so anyone can tell whether it is still current.
| File | What it contains | Owner | Review when |
|---|---|---|---|
| Positioning | The positioning statement, the category you compete in, and the alternatives buyers consider | Head of marketing | A competitor repositions or you change what you lead with |
| Brand voice | Tone rules, words you use and avoid, three short on-voice and off-voice examples | Whoever edits final copy | Drafts start sounding wrong in the same way twice |
| Ideal customer profiles | Who buys, the job they hire you for, their objections in their own words | Marketing, with input from sales | Win and loss reasons shift |
| Message house | The umbrella message, three or four pillars, and the proof under each pillar | Head of marketing | A pillar stops being provable or a new one appears |
| Product and pricing facts | Plans, prices, limits and what is not included, with the date checked | Product or founder | Any pricing or packaging change |
| Approved proof | Customer outcomes you are allowed to cite, with permission noted | Marketing | A customer approves or withdraws a quote |
Leave out anything that changes weekly. Last week of competitor posts, this month of ad results and the current content calendar are all snapshots, and a snapshot in project knowledge keeps getting cited long after it stopped being true. That material belongs in a live connection, covered below.
3. How do I write the project instructions?
Tell Claude what the project is for, which file wins when files disagree, what to do when a fact is missing, and what output format the team expects. Five short blocks, under a page.
Project instructions apply to every chat in the project [s2], so they are the place for rules, not content. The content lives in the knowledge files. Copy this structure and fill in the brackets.
A fill-in instructions template:
- State the job of the project. This project writes and reviews marketing for [brand]. Our buyers are [one line from the ICP file]. Every answer should be usable by a team of [size] without an analyst.
- Set the order of authority. When files disagree, the Positioning file wins, then Product and pricing facts, then Message house. Never contradict Product and pricing facts. If a file looks out of date, say so instead of quietly working around it.
- Say what to do with missing facts. If a claim needs a number, a customer name or a feature that is not in the knowledge files, leave a visible placeholder such as [NEEDS SOURCE] rather than inventing one.This single rule removes most of the fabricated proof points that make AI drafts unusable.
- Point at the voice rules. Write in the voice described in Brand voice. Before returning copy, check it against the words-to-avoid list and remove anything on it.
- Fix the output format. Return drafts as plain text with the channel named at the top. For briefs, use the headings Goal, Audience, Message pillar, Proof, Call to action.
4. Should a team have one project or several?
One project per job, all loading the same core files. A content project, a competitive project and a reporting project each need different instructions, but they should share one positioning file rather than three copies.
| Project | Extra knowledge beyond the core files | Instruction focus |
|---|---|---|
| Content | Content pillars, channel rules, reusable post templates | Draft to a pillar, match the channel, flag missing proof |
| Competitive | One dated profile per competitor (Veltrix, Sondera, Norvane), battlecards | Separate their claims from evidence, never state their pricing without a date |
| Reporting | Metric definitions, last quarter targets, the report template | Use only the numbers supplied in the chat, explain changes, never estimate |
The risk with several projects is drift: someone updates the positioning in one and forgets the others. Keep a master copy of each core file in your normal document storage, and treat project uploads as copies that get replaced, never edited in place.
Agencies and multi-brand teams should split by brand before splitting by job. Two brands in one project means the model will eventually borrow one brand's proof point for the other.
5. How do I keep the shared context from going stale?
Put a date and an owner at the top of every file, review on events rather than on a calendar, and replace whole files instead of patching them. Stale shared context is worse than none, because everyone trusts it.
- Head every file with a date and an owner. Start each knowledge file with a line such as Last reviewed 2026-09-28 by Dana. Add a line to the instructions asking Claude to mention the date when a draft leans on a file older than a quarter.
- List the events that trigger a review. A pricing change, a new competitor claim you need to answer, a lost deal with a new reason, a product launch. Each maps to one file in the table above, so the owner knows what to reopen.
- Replace, do not patch. Edit the master copy, then delete the old upload and add the new one. Two versions of the positioning in the same project is how drafts end up quoting a claim you retired.
- Keep a short change note. A single file listing what changed, when and why lets anyone see that the Message house moved last week, and why older drafts read differently.
6. What does a Project not do?
It does not watch anything. Project knowledge is whatever you uploaded, so it cannot tell you a competitor changed their pricing yesterday. Live questions need a connector to a system that tracks the data.
A Project is a filing cabinet, not a feed. It answers well about the things you wrote down and badly about anything that moved since. Asking a project chat what Veltrix is running on Meta this week produces either a refusal or, worse, an answer built from last month's upload.
For current data, connect a source instead of uploading exports. Claude supports custom connectors over remote MCP on every plan, with free accounts limited to one [s3]. The split that works: the Project holds the slow layer (who you are, how you sound, what you claim), and a connector supplies the fast layer (what changed).
Key Takeaways
The value is consistency
One positioning file used by every chat produces one brand. Five pasted versions produce five slightly different ones.
Stable material only
Positioning, voice, ICPs, message house and product facts belong in knowledge. Weekly data does not, because snapshots go stale while still being cited.
Instructions carry rules, files carry content
Say which file wins in a conflict and what to do when a fact is missing. A visible placeholder rule prevents invented proof.
Date and own every file
A reviewer can only trust shared context if they can see when it was last checked and who is responsible for it.
Split by brand first, then by job
Separate projects per job can share one set of core files. Separate brands must never share a project.
Live data needs a connector
A Project cannot watch the market. Pair it with an MCP connection for anything that changes week to week.
Frequently Asked Questions
Sources
- What are projects? Anthropic, September 2026.Official definition of Projects, plan availability and the free-plan project limit.
- How can I create and manage projects? Anthropic, September 2026.Project instructions, knowledge, the no-shared-context rule, retrieval mode and sharing permissions.
- Get started with custom connectors using remote MCP Anthropic, September 2026.Plan availability of custom connectors and the security guidance for connecting them.
Explore More
Related analyses, benchmarks, and industry insights
Related Guides
Glossary Terms
Turn reading into a reaction
Oppira watches your competitors, keeps your playbook current, and drafts the response. See your market clearly by tomorrow.