Every firm has knowledge that lives in the wrong place. The way you structure a demand letter is in a partner's head. The intake questions for a custody matter are in a paralegal's notes. The firm's writing style exists only as the redlines that come back on every associate's first draft. When someone leaves, that knowledge leaves with them.
Claude Projects are the most practical tool we have found for capturing that knowledge in a form people actually use. A Project is a workspace in Claude that holds a set of instructions and a set of reference files, so that every conversation started inside it begins with the same context. This page is about building them well.
What a Project holds and what it does not
A Project has two parts. Instructions are a block of text that tells Claude how to behave in that Project: the role, the style, the rules, the output format. Files are documents you upload as reference: exemplars, checklists, glossaries, templates. Every chat inside the Project can draw on both without your having to re-explain.
A Project is not a document management system, and it is not a substitute for your case management platform. It holds a curated few dozen reference documents, not the firm's files. Nor is it a memory of past conversations across users. Think of it as a well-briefed colleague who has read the firm's style guide and the best three examples of each document type, and nothing else.
On the Claude Team and Enterprise plans, Projects can be shared with colleagues, and admin controls govern who can create and see them. Those plans also state that customer data is not used for training by default; confirm the current terms yourself before uploading client material. Our Claude for law firms page covers plan selection in more detail.
Six Projects most firms should build first
The first is a firm writing style Project: instructions describing tone, sentence length, formatting rules, and banned phrases, plus three or four of the firm's best-written documents as files. Every other Project can borrow from it.
The second is intake summarization, one per major practice area, with the intake questionnaire and a completed example summary. The third is deposition and transcript work, with instructions for timeline format and page citation rules. The fourth is client communication, with examples of status letters and the plain-language conventions the firm uses.
The fifth is a matter-type playbook: for a personal injury pre-litigation matter, the phases, the documents produced in each, and the checklists. The sixth is internal process: how to open a matter, how to bill, how to close a file, so that new staff can ask questions of the Project instead of interrupting a colleague.
Writing project instructions that behave like a style guide
Instructions should read like a memo to a new hire, not like a prompt. Say who Claude is in this context ("you are assisting paralegals at a family law firm with intake summaries"). Say what the output looks like, with headings named. State the rules that matter most, in order: cite the source paragraph for every fact, flag missing information rather than guessing, never state a legal conclusion, use the firm's terminology from the glossary file.
Keep it under a page. Long instruction blocks get skimmed by the model in the same way long policies get skimmed by people. If a rule is important enough to be in the instructions, it is important enough to test: run three real examples through the Project and see whether the rule was followed. Revise until it is.
Choosing what to upload (and what to leave out)
Upload exemplars, not archives. Three excellent demand letters teach more than thirty average ones. Upload checklists and templates the firm already uses, because they encode decisions that took years to make. Upload a glossary if your practice area has terms of art that a general model might misuse.
Leave out anything the firm's AI policy keeps out of the tool, and redact exemplars before uploading them if they contain client information you would not otherwise put in the tool. Leave out documents that contradict each other; the Project will follow both and produce something inconsistent. For fixed-form documents where only the names and dates change, the right home is document automation in your case management system, not a Project.
Sharing, permissions, and keeping Projects current
Assign an owner to each Project, typically the person who knows that workflow best. The owner updates the instructions when the process changes and swaps exemplars when a better one is written. Set a review cadence, quarterly is usually enough, and put it on the owner's calendar.
Share Projects by role, not firm-wide. Intake staff need the intake Projects; litigation support needs the transcript Projects. This keeps each person's Project list short and makes the training simpler, which is why our AI training for paralegals and legal staff is organized around the Projects each role will use. Retire Projects nobody has opened in a quarter. A stale Project with outdated instructions is worse than none, because people trust it. This is a core piece of what we build in our Claude training for lawyers engagements.
Questions we get
How many Projects should a firm have?
Start with six or fewer. A firm with forty Projects has a discovery problem: nobody can find the right one, so they use none. Add a Project when a workflow is repeated weekly by more than one person and has a stable structure. Merge Projects when two of them have overlapping instructions.
Can a Project replace our brief bank or form library?
No, and it should not try. The form library holds hundreds of documents for retrieval. A Project holds a handful of the best ones so the model can imitate them. Keep the library where it is and point the Project at its best entries.
What happens when the model is updated?
Instructions and files stay as they are. Output may shift slightly in style. That is another reason to keep three test examples for each Project: run them after any significant change and confirm the rules still hold. The owner can then adjust the instructions if needed.
If you want help deciding which Projects to build first and writing the instructions for them, tell us what you are working with.