Setting Up a Project Checklist
A Claude Project is a persistent workspace: its configuration carries forward automatically into every future conversation, for every teammate with access — nobody re-pastes or re-explains it.
| Lever | Holds | Example |
|---|---|---|
| Custom instructions | Standing behavior: role, tone, house rules | "You are reviewing vendor contracts; flag clauses that deviate from the uploaded template" |
| Knowledge base | Reference material Claude can search and quote from | The standard-terms template, a library of past contracts |
Supported knowledge base formats: DOCX, PDF, and plain text upload directly — no conversion required.
- Instructions describing a document's contents in prose are a poor substitute for the real document being searchable in the knowledge base.
- An uploaded document with no instructions leaves Claude guessing how you want it used — configure both levers, not just one.
- Give files clear, current names; don't upload two versions of the same reference side by side.
- Not the same as prompt caching — caching optimizes repeated content within a session; the knowledge base upload is what makes content persist across conversations.
Connectors at a Glance
A connector gives Claude live access to an external source, in contrast to a knowledge base upload, which is a fixed snapshot as of when it was uploaded.
| Connector | Read | Write |
|---|---|---|
| Google Drive | Search and read current files without manual copy-paste | Create folders and save Claude-generated files directly into Drive |
| Gmail | Search and read messages/threads to ground a task in the current state | Not covered — read access is the described use case |
Decision rule: stable, once-reviewed material (a finalized style guide) fits a knowledge base upload. Material that changes on its own schedule (an inbox, a live spreadsheet, a shared planning doc) fits a connector instead.
Enable a connector once (connect and authorize); it's then available going forward without repeating setup on every task. Different connectors support different read/write combinations — check what a specific one supports rather than assuming they all behave the same.
Writing Durable Project Instructions
The test: not "does this work for the task I have right now" but "will this still make sense for the next five different requests a teammate sends into this Project next month."
What belongs in standing instructions:
- Role — who Claude is acting as for this Project
- Scope — what kinds of requests the Project is (and isn't) for
- Knowledge source priority — which document or connector is authoritative when more than one is available
- House style/format defaults — applied unless a specific message overrides them
| Do | Don't |
|---|---|
| State a durable role and style ("friendly, concise, one clear call to action") | Name a specific one-time dataset, deadline, or request in the instructions |
| Supply task-specific detail fresh in each conversation's message | Bake this month's task into the standing instructions |
| Say which source wins when documents conflict | Leave source priority unstated when multiple sources exist |
The narrow-instructions trap: instructions modeled on the first real task ("Use the Q3 launch data to draft this month's newsletter") work once, then break on the next, different request. Fix: separate the durable role/style from the task-specific detail and drop the task-specific part from the instructions entirely.
Signs a Project's Configuration Has Gone Stale
A Project that was accurate in January can be confidently, fluently wrong by August — and Claude answers just as confidently either way, so nothing in the output itself signals the drift.
- An uploaded document has been superseded elsewhere, but the old file is still in the knowledge base (and possibly still treated as authoritative).
- Instructions reference a process, tool, or team structure that's since changed.
- Multiple versions of the same document have accumulated in the knowledge base with none removed, so Claude has no reliable way to know which is current.
Fix the actual file or instruction, not the prompt or a single conversation — a stale answer traces back to outdated configuration, and no amount of prompt-level care corrects an outdated uploaded document.
Maintenance: Ownership and Review Cadence
Configuring a Project well solves the problem as of the day it was set up — it doesn't solve it permanently. Treat configuration as living infrastructure, like a shared wiki page or runbook.
- Single-user Projects: staleness is usually caught quickly because that person notices when something feels off.
- Shared Projects: nobody is naturally positioned to notice drift unless someone is explicitly accountable for it.
- Assign an owner — not necessarily the original creator, just someone responsible for periodically reviewing instructions and the knowledge base.
- Set a lightweight cadence — a recurring reminder to spend fifteen minutes reviewing a shared Project's configuration is enough to catch most drift.
- Remove, don't just supersede — when replacing an outdated file, delete the old version rather than leaving both in the knowledge base.