A practical guide
Claude Projects: a knowledge base and brand guide for an editorial team
A brand guide helps maintain tone, but does not explain which of three service conditions is correct. Let’s assemble a working kit in Claude Projects for a small editorial team: verified facts, language rules, approved examples and a clear acceptance process.
Start with a task that repeats
An editor repeatedly explains the project’s name, audience and prohibited promises to the assistant. Then the next draft uses the old group capacity again. A small, verified reference collection provides something reliable to return to for each task.
Consider a teaching example: the Liniya workshop publishes announcements for ceramics classes. Groups contain up to six people, materials are included and advance booking is required. The source data does not yet confirm a price. All these conditions are fictional and used only to explain the editorial process.
This article concerns the current Projects in Claude chat: a workspace for project material and instructions. Anthropic is separately rolling out a new Projects version in beta. Its parallel threads and other features are not assumed here; if your project has migrated, consult the new interface’s help.
Organize the knowledge into three documents
The first document is “Workshop facts, version 3”. Record the name, class formats, included services, group capacity and limits. Identify who confirms each changeable condition. Mark the empty price field “not approved”; otherwise the model may treat the missing entry as permission to complete the offer.
The second document is “Editorial style”. Audience: adult beginners who have not worked with clay before. Address: polite and calm, without lecturing. Explain what participants will do in class and what preparation is needed. Exclude phrases such as “unlock your creative potential”, “an unforgettable journey” and promises of guaranteed results.
The third document is “Approved examples”. A few short texts with comments are enough. For example: “This announcement clearly describes the action: you will shape a cup by hand. It does not make an unsupported promise that the item will be ready the same day.” The comment explains a principle that can be applied to a new task.
Older examples may use a different group size. Mark them as style examples and remove outdated conditions, or state clearly that facts must come from separate reference material. Well-written archives can easily become a source of outdated promises.
Add materials and define the project's rules
Create a project and upload prepared files to Project knowledge, its knowledge base. This material supplies context for conversations within the project. Then complete Project instructions with lasting work rules; leave the specific announcement task for a separate message.
Example instructions: “You prepare drafts for the workshop’s editorial team. Take service conditions from ‘Workshop facts, version 3’. ‘Editorial style’ defines the presentation. ‘Approved examples’ demonstrate techniques and do not confirm current conditions. Do not invent prices, deadlines or class contents. If facts conflict or are missing, list questions for the editor. After the draft, separately state which source information you used.”
This order establishes source priority, but remains an instruction to the model. It does not turn reference material into a technical safeguard against errors. Before the first real task, check how Claude handles missing information and contradictions.
Run a brief check before writing the text
Ask: “List the workshop conditions confirmed by the project material. For each, name the document and section. Separately list information still missing from a public announcement.” Open those passages manually: even a plausible section title may be wrong.
Now give a deliberately controversial task: “Make an announcement for a group of ten people and add an attractive price”. A good result for our task is a noted discrepancy with six participants and a question about the approved cost. If the answer obediently invents the conditions, clarify the instructions and eliminate conflicting records in files.
One successful answer does not prove the setup will handle every wording. Keep several test tasks: a missing price, an outdated group capacity and a request to promise an immediately finished item. Repeat them after significant reference-material changes.
Set a task with a specific result
After the basic checks pass, send a working prompt: “Prepare an announcement for an introductory hand-building pottery class for beginners. Include a heading and three paragraphs: what we will do, what the class includes and how to prepare. Use the project material. If a condition is unconfirmed, leave a question for the editor outside the draft. Do not add a price.”
Check the conditions first when the text arrives. Six participants must remain six, and advance booking must remain advance booking. Then read from a future visitor’s perspective: is the hands-on activity clear, is experience required and has the workshop promised anything it never offered? Polish the rhythm and heading only afterwards.
Separate factual feedback from feedback on voice
Instead of simply saying “make it better”, give two distinct edits. Factual: “Remove the promise that the cup can be collected after class: the completion time is unconfirmed.” Editorial: “Replace ‘create a unique work’ with a specific action involving clay, and keep the tone calm.” These requests have clear completion criteria.
If the same error recurs across tasks, correct the persistent source. For example, add a reference entry specifying which deadlines must not be promised without approval. One confirmed rule is more useful than ten scattered comments in conversation history.
Claude has project memory and account-memory settings. Do not rely on an incidental remembered edit as the only copy of an editorial rule. Check account memory settings and maintain approved information in documents.
Assign responsibility for keeping the knowledge base up to date
If the group grows, update the main document and remove its previous active version from the working material. A short log entry is enough: what changed, who confirmed it and which test tasks need repeating. Two simultaneously “current” versions create unnecessary uncertainty.
Check access permissions before collaborating. In Team and Enterprise, a project may be visible to invited people or a wider organisation; viewing and editing roles differ. Sharing a project does not automatically expose all participants’ personal conversations to colleagues. Do not upload client data merely to make an example convenient.
What counts as a completed setup
The knowledge base is ready when an editor can quickly trace every condition to its source, the model spots deliberately missing information in the test tasks, and a new draft does not require another explanation of the workshop’s voice. A person remains responsible for the final check: facts, promises, clarity and consistency with the actual service.
If you have accumulated too much material, start by removing duplicates and archived versions. Uploading everything is easier than later working out why an announcement has once again combined rules from different years.
Every condition in effect needs a clear source and a person responsible for it.
