Claude Projects Setup Guide for Professionals (2026)

TL;DR. A practical, step-by-step guide to setting up a Claude Project as a coworker for professional work. Custom instructions structure, knowledge uploads, and maintenance.

Most professionals who try Claude give up within a week. Not because it doesn't work, but because they're using it wrong: as a one-off chatbot where every conversation starts from scratch. The fix is Claude Projects, and the fix takes about 30 minutes to set up properly.

Done well, a Project becomes a coworker you don't have to re-explain yourself to. Done badly, it becomes a liability surface — client PII embedded in workspace knowledge, voice instructions that leak privileged language into AI-drafted communications, stale templates that produce wrong outputs to real clients. This is the canonical guide for getting to the version that works without creating the version that gets you sued.

What a Claude Project actually is

A Project in Claude.ai is a persistent workspace with three parts:

1. Custom instructions — a text block that Claude reads at the start of every conversation in the Project. This is where your voice, your rules, and your context live.
2. Project knowledge — documents you upload once that Claude can reference across all conversations in the Project.
3. Chat history — every conversation you've had inside the Project, searchable and organized.

Once you've set up a Project, every new chat inside it starts with Claude already knowing who you are, how you write, and what you care about. No more re-explaining.

The four-part custom instructions structure

The single biggest mistake professionals make is writing vague custom instructions. "Be helpful and professional" is not an instruction. It's a wish. Use this structure instead:

1. Profile. Who you are, what you do, who you serve, what constraints you work under. For a paralegal, this might be "I'm a paralegal at a mid-size commercial litigation firm. I support three partners. I draft discovery requests, summarize depositions, and prepare exhibit binders. I'm not a lawyer and I never give legal advice."

2. Voice. How you write. Specific examples beat adjectives. "Short sentences. No filler. Use contractions. Never use 'unlock,' 'leverage,' or 'seamless.' Prefer concrete examples over abstract claims." If you have a writing sample you're proud of, paste a paragraph of it and say "match this tone."

3. Rules. Hard constraints that must never be violated. "Never invent facts I didn't provide. Never include patient identifiers in outputs. Always tie clinical language to documented findings." This is where professional defensibility lives. Be explicit. Claude will follow explicit rules.

4. Formatting. What outputs should look like. "Default to bullet points for lists longer than three items. Never use headers in short replies. Always put action items at the top of a response, not the bottom." The more specific you are, the less editing you do later.

A well-built custom instructions block is usually 200 to 500 words. Much shorter and it's too vague. Much longer and Claude starts losing pieces of it in long conversations.

What to upload to project knowledge

Project knowledge is for reference material, not for working documents. Good candidates:

• Your style guide or voice guide. If your firm has one, upload it. If not, write a one-pager and upload that.
• Templates you reuse. Standard engagement letters, SOAP note templates, listing description templates, proposal skeletons.
• Policy documents you reference constantly. A pharmacy's formulary rules. A firm's conflict-check process. A brokerage's disclosure requirements.
• Examples of good outputs. Three or four real examples of work you're proud of. Claude learns your standards from examples faster than from descriptions.

Bad candidates for project knowledge: individual client files, patient charts, one-time matter documents, anything confidential that shouldn't live in a long-lived workspace. Those belong in the chat itself, not in persistent knowledge.

The PII problem nobody talks about

Most professionals dump example documents into Project knowledge without checking what's in them. Project knowledge persists across the workspace lifecycle — if you uploaded a "good example" letter with a real client's name, address, and matter details, that data is now in your workspace until you remove it.

Three rules that hold up across professions:

1. Strip identifiers before upload. Use placeholders ([CLIENT], [MATTER NUMBER], [PATIENT INITIALS]) in every reference document. The example teaches the structure; the structure doesn't need the real person.
2. Treat Project knowledge as if it might be reviewed. It probably won't be. But the discipline of writing it as if it might be is what keeps you out of trouble when something unexpected happens — a vendor change, a discovery request, an internal audit.
3. Check your plan's data-handling posture. Anthropic publishes its policies on training, retention, and enterprise data handling. For regulated professions, read them before uploading anything that touches client confidentiality, and consult your firm's IT / compliance team if the plan's posture doesn't match your obligations.

How to maintain a Project over time

Projects decay if you don't maintain them. Here's the maintenance cadence that actually works:

Weekly (5 minutes). Skim your recent chats. If you caught yourself re-prompting Claude for the same correction twice, add that correction to your custom instructions. Every correction you add is one you'll never make again.

Monthly (15 minutes). Re-read your custom instructions top to bottom. Remove anything that's no longer true. Add anything that's become standard. Delete rules you've stopped caring about.

Quarterly (30 minutes). Audit your project knowledge. Remove outdated templates. Add new reference documents. Make sure nothing in there is stale or contradictory.

Profession-specific examples

The same four-part structure adapts to every profession. Four worked examples to illustrate:

How a financial advisor sets up a Plan Review project

Profile section names the advisor's licensure (Series 65, CFP, or whichever applies), the firm's compliance framework (Reg BI for broker-dealers, RIA fiduciary standard for independents), and the client segment they serve. Voice section captures the firm's house style on client letters. Rules section is dense: "Never characterize a recommendation as advice tailored to a specific client unless the chart they paid for supports it. Always reference the Investment Policy Statement when discussing rebalancing. Never include performance projections without the firm's required disclosures." Formatting section specifies the standard letter format and the required disclosure footer. Project knowledge holds the firm's compliance-approved disclosure templates and (de-identified) examples of well-written letters. See /professions/financial-advisor for the full setup.

How a personal trainer sets up a Client Programs project

Profile names the trainer's certification (NASM, ACE, NSCA, ACSM) and scope. Voice captures the trainer's coaching style. Rules section names the boundaries — "I am not a registered dietitian; refer medical-nutrition therapy out. I am not a physical therapist; refer pain or injury to a PT. I never give medical advice." Formatting specifies the program-document structure (warm-up, work sets, conditioning, mobility). Project knowledge holds (de-identified) example programs at different client levels. See /professions/personal-trainer for the full setup.

How a construction PM sets up a Change Order project

Profile names the contractor, the contract form (AIA, ConsensusDocs, custom), and the project. Voice is professional and factual. Rules section captures the contract's change-order pricing rules — labor and material markups, schedule analysis requirements, attachment standards. Formatting specifies the change-order template the owner expects. Project knowledge holds the contract's general conditions and the prior change orders on the project. See /professions/construction-pm for the full setup.

How a paralegal sets up a Discovery Drafting project

Profile names the firm, the practice area, and the paralegal's role. Voice captures the firm's drafting conventions. Rules section is critical: "I am not a lawyer and never give legal advice. All drafts go to the supervising attorney for review before any external use. Never include privileged or work-product information in a chat I'm not certain is privileged." Formatting captures the firm's discovery-request templates. Project knowledge holds (sanitized) prior discovery sets in the practice area. See /professions/paralegal for the full setup.

Other worked setups: /professions/therapist for clinical documentation workflows, /professions/attorney for legal drafting and review, /professions/real-estate for listing and client communication, /professions/management-consultant for proposals and client memos.

The 30-minute version

If you want the fastest possible setup: create a new Project, paste a four-part custom instructions block (profile, voice, rules, formatting), upload two or three reference documents, and start using it. Refine weekly. Don't overthink the first version.

A rough Project you actually use beats a perfect Project you never ship. Start messy. Maintain consistently.

Start with one Project for your single highest-volume document type. Pair it with the corresponding tool in the /tools library to validate the workflow on a few real (de-identified) documents before scaling the Project to more of your work. Create your free AI Career Lab account at /sign-up to access profession-specific cowork guides and templates.

---

This article is general guidance for professionals using Claude Projects as a workflow tool. It is not legal, compliance, or data-handling advice. Specific obligations under FERPA, HIPAA, attorney-client privilege, financial-advisor compliance frameworks, and your firm's data-handling policies govern actual Project setup in your environment. When in doubt, your firm's IT and compliance teams are the appropriate resources.