Every new chat makes Claude a stranger again
You explain the codebase. You paste the style guide. You re-describe the client, the constraints, the one legacy decision you have to live with. Then the chat gets long, you start a fresh one, and you do it all again.
That re-briefing tax is a big part of why AI assistants still feel like a demo instead of a coworker. Claude Projects exist to remove it: a workspace where your instructions, files, and context live in one place, so every conversation inside it starts already knowing your work.
What a Project actually is
A Project bundles three things:
- Custom instructions that apply to every chat in the Project.
- Project knowledge: files and text you upload once (docs, specs, schemas, style guides).
- A shared context boundary: every conversation you start inside the Project can draw on those instructions and that knowledge, without you pasting anything.
A Project is not a longer chat. It is a room: you walk in, the reference material is already on the shelves, the house rules are on the wall, and each conversation is a separate desk. What you learn at one desk does not carry to the next, but the shelves and the rules are shared.
Write instructions like a job description, not a wish
The weakest Projects have instructions like "You are a helpful assistant for my startup." That tells Claude nothing it did not already assume.
Treat the instructions as onboarding for a competent new hire. Cover role, constraints, and output shape:
Role: You help maintain a Django + Postgres API for a logistics app.
Audience: mid-level backend devs on our team.
Rules:
- Match our style guide (see knowledge). Type hints required.
- Prefer stdlib and existing deps; ask before adding a package.
- When unsure about business logic, ask instead of guessing.
Output: code first, then a short "why" note. No filler intros.
Constraints do more work than encouragement. "Ask before adding a package" prevents more bad output than any amount of "be smart and thorough."
Curate knowledge, do not dump a drive
It is tempting to upload everything. Resist it. Project knowledge is signal you are handing the model, and noise dilutes it. An outdated PRD sitting next to the current spec gets cited as if both are true.
Good candidates: the current architecture overview, the API schema, the style guide, a glossary of domain terms, a few representative examples of "good" output. Bad candidates: entire meeting-note archives, superseded drafts, anything you would not want quoted back at you as fact.
If a file has a stale section, trim it before uploading. You are curating a reference shelf, not backing up a folder.
Add a map file
One small file earns its place fast: a short index, something like _START_HERE.md, that says what every other file is and when to trust it.
- architecture.md : current system design. Source of truth.
- style-guide.md : code conventions. Always apply.
- glossary.md : domain terms (a "shipment" != an "order").
- old-spec.md : historical only. Do NOT treat as current.
This gives Claude a way to weigh sources instead of averaging them, and it forces you to notice what is actually in the Project.
Keep it fresh (the step everyone skips)
A Project is manual memory. Nothing updates itself. The schema changes, the file does not, and now your assistant is confidently wrong in a way that is harder to catch than an obvious blank.
Build a small habit: when a decision changes, update the one file that records it, the way you would a README. Stale context is worse than no context, because it reads as authoritative.
Where Projects are weaker
The honest limits, because they change how you use it:
- Not a live knowledge base. A Project reflects what you last uploaded, not your repo's current state. For code that changes hourly, it drifts fast.
- Retrieval is not exact. Large knowledge sets get drawn on selectively, not read cover to cover on every message. Ten focused files beat a hundred loosely relevant ones.
- Scope is a boundary, not a brain. Context does not carry between Projects. That is good for isolation, but it means you maintain each one by hand.
- Sensitive material is still material you put somewhere. Client data and secrets in a Project deserve the same judgment you would apply to any shared workspace.
None of this makes Projects less useful. You just want to know the edges before you lean on them.
A minimal starting point
Create one Project per real domain (one codebase, one client, one book), not a single mega-Project. Give it three files to start: a map, an architecture or overview doc, and a style guide. Write ten lines of real instructions. Then start a chat, watch what it still gets wrong, and fix the file instead of the prompt.
Do that for a week and the pattern changes: you stop introducing yourself, and Claude starts picking up where you left off.
I write about turning AI from a chat toy into a working tool. I help build AGINE Academy, a game-based academy for learning Claude by real practice. It is an independent product and is not affiliated with Anthropic.
Top comments (0)