Home › Study guides › CCAO-F › Domain 5 › Lesson 5.1

CCAO-F · Domain 5 · 12% of the exam · Lesson 5.1 · 19 min read

Configuring a Claude Project: instructions and knowledge

What belongs in a Claude Project's instructions and knowledge, what stays in the prompt, and how to test and share a Project before a team relies on it.

Written against objective 5.1 of the official CCAO-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

5.1.1 Why twelve proposal writers get twelve different answers

Marisol runs sales enablement at Brindle Works, a company that sells shift-scheduling software to mid-sized manufacturers. Twelve account executives answer requests for proposal (RFPs), and all twelve draft their proposals with Claude, each in their own chats, pasting in whichever product sheet and case studies they have saved. Last month one proposal promised a feature that was retired in the spring. Another offered a three-year discount that only the deal desk, the team that approves special pricing, can sign off. A third quoted a customer who never agreed to be named.

None of this is Claude misbehaving. Claude only knows what is in front of it, and across twelve separate chats that means twelve piles of pasted material and twelve memories of the pricing rules. When someone pastes last year's fact sheet, Claude has no way to know it is out of date. The team does not have a prompting problem. It has a setup problem: the same rules and the same approved documents need to be in front of Claude every time, without anyone having to remember them.

That is the job of a Project: a workspace in the Claude apps with its own chats, its own instructions, which Claude follows in every chat inside it, and its own knowledge, the files Claude draws on in those chats. Marisol is going to build one called Proposal Writer. The work is deciding what goes in the instructions, what goes in the knowledge and what stays in each prompt, then checking it all before twelve people rely on it.

5.1.2 What a Project is, and when it earns its place

It is tempting to think of a Project as a folder for chats about one topic. What matters more is what each new chat starts with: in Proposal Writer, the discount rule and the approved pricing guidelines are already there, and nobody had to paste them.

What a Project does not do is pass what was said in one chat on to the next. Anthropic's Help Center is explicit: context is not shared across chats within a Project unless the information is added to the project knowledge. Picture an agency that sends a different temp each morning with the same briefing pack: the pack reaches every temp, but a correction told to Monday's temp never reaches Tuesday's. So when one executive tells Claude "we retired that feature", the correction stays in that conversation, and the other executives' chats cannot count on it. To fix something for every chat, change the instructions or the knowledge.

A Project takes effort to set up and keep current, so it earns its place when work repeats. Anthropic's Claude 101 course suggests one when you have reference material you will use again and again, consistent requirements for how Claude should respond, or several people who need the same foundation. Proposal Writer has all three; a single thank-you note to a partner needs only a plain chat. Projects are available on every plan, and free accounts can create up to five.

One condition comes before building: knowing which documents are the approved ones. Three pricing sheets are in circulation at Brindle, and nobody is sure which one the deal desk signed off. A Project built on that confusion would repeat it in every chat, so Marisol settles it with the deal desk first.

5.1.3 Instructions, knowledge and the prompt: what goes where

Here is the question this objective keeps returning to: you have a rule or a document ready to add, so where does it belong? A Project offers three homes, and the test is how long the thing stays true. The instructions hold the durable HOW, the way the work is always done. The knowledge holds the approved reference WHAT, the documents it is done with. The prompt holds this task: this client, this request, this deadline.

Picture a restaurant kitchen: the house rules on the wall say how every plate goes out, the pantry holds the checked ingredients, and the order ticket says what table six wants tonight. The cook needs all three, but nobody pins tonight's order to the wall.

Memorise the rule of thumb behind the table: a rule for every chat goes in the instructions, a document to work from goes in the knowledge, and anything about one job stays in the prompt. Each wrong home fails in its own way. A price list pasted into the instructions is a document in the wrong home; kept as a file, it could be swapped whole when prices change. One client's details in the instructions leak into every other proposal. A durable rule left to each prompt depends on twelve people remembering it.

One field looks like a home but is not: the Help Center notes that Claude has no access to a Project's name or description, which are there for people. Anything Claude must follow goes in the instructions.

Here is Marisol's first draft of the instructions. Look at how it points to the knowledge files by name instead of copying them, and at the lines that say what to do when the files have no answer.

You help Brindle Works' account executives draft proposals for mid-sized manufacturers. Readers are operations and finance leads comparing several vendors; they skim.

Follow the section order in "Proposal template 2026". Keep each section under 250 words, plain and confident, with no superlatives.

Take every product fact from "Product fact sheet - current release". If the RFP asks for something the fact sheet does not cover, write [CONFIRM WITH PRODUCT] instead of describing a feature.

Take every price from "Pricing guidelines". For any discount outside the guideline bands, write [DEAL DESK REVIEW] and give no figure.

Name only customers from the case studies in this Project; each one has agreed to be referenced.

End each draft with a list of the assumptions you made and the flags you raised, so the executive can check them before sending.

5.1.4 Choosing the knowledge: approved, current, relevant

With the pricing question settled, Marisol's next instinct is generous: upload the whole shared sales folder, all 140 files, so Claude "has everything". It feels thorough, and it is the quickest way to spoil a Project. The folder still holds all three pricing sheets, case studies customers never approved, a two-year-old roadmap deck and a spreadsheet of past deal margins.

Claude treats every file in the knowledge as material it may use, and nothing in the folder says which pricing sheet was replaced. When two files disagree, one chat may lean on the first and the next on the second, so the answers vary. Claude 101 puts it plainly: outdated documents can lead to outdated responses. Volume has a cost too. Anthropic's engineers describe a model's attention as a limited budget, and every extra page draws on it.

So every candidate file faces three questions. Is it approved by its owner? Is it current, not replaced by something newer? Is it relevant to writing proposals, the purpose of this Project? Completeness within that purpose helps; anything outside it is noise. The margin spreadsheet fails a fourth test as well: every member of a shared Project can see its knowledge, and executives should not see other deals' margins.

Two habits help the files that make the cut. Give them descriptive names, because Claude uses file names to find the right material: "Pricing guidelines 2026-09" beats "pricing_final_v3". And keep one-off material out: each client's RFP is uploaded in that client's chat, where it stays separate from the project knowledge.

5.1.5 When the knowledge is large, Claude searches it

Does Claude read every file in the knowledge before each answer? When the files fit, in effect yes: Claude uses them as context in every chat. But every model has a limit on how much it can hold in view at once, called its context window. On paid plans (Pro, Max, Team and Enterprise), when the knowledge approaches that limit, the Project switches automatically to retrieval augmented generation, or RAG. The Free plan does not include RAG, so there the knowledge has to fit within the context window.

In RAG mode, Claude uses a project knowledge search tool to find the passages most relevant to each question and works from those. The Help Center says this lets a Project hold up to ten times more content, needs no setup and keeps response quality consistent.

A small Project is papers spread on your desk: everything is in view. A large one is an archive with a fast clerk who brings back the folders that best match your question. The precise point is that the clerk matches on how well a passage fits the question, not on which document your company approved. Ask about three-year pricing, and a superseded pricing sheet matches just as well as the current one.

So a large Project needs curation just as much as a small one. The Help Center also suggests naming the document in your prompt: "Using the pricing guidelines, what can we offer Wrenfield on a three-year term?" tells the search where to look.

5.1.6 Test it, then share it with the team

Before twelve people rely on Proposal Writer, Marisol tests it. The cheapest check is a handful of representative questions whose right answers you already know. She picks three past RFPs that Brindle won, so she has the proposals the team actually sent, each probing a different part of the setup.

The Harlow test fails at first: the draft quotes a three-year price worked out from the annual list price, because her pricing rule mentioned only discounts. Correcting the draft in the test chat would fix that one draft and nothing in the twelve executives' chats to come. So she adds "or any multi-year pricing" to the pricing rule and reruns all three tests. The same logic holds after launch: when several people's chats make the same mistake, the cause is the shared configuration.

Only now does she share it. On Team and Enterprise plans, you can share a Project with invited colleagues or with your whole organisation, unless your organisation's owners have turned sharing off. Each person you invite gets one of two permission levels. Can view members see the contents, knowledge and instructions and can chat in the Project, but cannot change it. Can edit members can change the instructions and knowledge and manage members.

Marisol gives the twelve executives Can view, and Can edit only to the deal-desk lead who owns the pricing guidelines; as the Project's creator, she keeps control herself. Every change to the configuration reaches every executive's next chat, so the people who own the sources should be the ones who change them.

5.1.7 The exam traps

Most traps in this objective put something in the wrong home or skip a check before rollout.

• ✗ Uploading the whole shared folder so Claude "has everything". ✓ Add only approved, current, relevant documents. Drafts and superseded versions become sources Claude may use.
• ✗ Putting a whole reference document, or one client's details, into the instructions. ✓ Keep documents in the knowledge and task specifics in the prompt. Instructions hold the rules and apply to every chat, so a one-off detail leaks into unrelated work.
• ✗ Correcting a repeated mistake in each chat as it appears. ✓ Fix the instructions or the knowledge. A correction in one chat does not reach the others.
• ✗ Building a Project for a one-off, or before anyone knows which sources are approved. ✓ Confirm the work recurs and settle the authoritative sources first. A one-off needs only a plain chat.
• ✗ Rolling a Project out untested, or asking Claude whether the setup is right. ✓ Run a few representative questions with known answers, including awkward ones. Confidence is not evidence.

5.1.8 Put it together: set up a Project your team can rely on

You now have every piece. Each rule or document has a home, curation matters whether the knowledge is read whole or searched, and testing before sharing makes a Project safe for a team. The fastest way to feel why curation matters is to spoil the knowledge on purpose.

The rest of Domain 5 builds on this setup. Managing uploads and connectors (5.2) decides whether a document sits in the Project as an uploaded copy or is read from a tool such as Google Drive. Creating system-level instructions (5.3) turns the instructions you sketched here into guidance that holds up, alongside your account-wide instructions. And maintenance (5.4) keeps the knowledge and instructions current as prices, products and policies change.

Key takeaways

• ✓ A Project is a workspace whose instructions and knowledge come into every chat inside it; its chats do not share context with each other.
• ✓ Use a Project for recurring work with the same rules and files, once you know which sources are approved; a one-off needs only a plain chat.
• ✓ Instructions hold the durable how, knowledge holds the approved reference documents, and the prompt holds this task's specifics.
• ✓ Curate knowledge to approved, current, relevant files with clear names; superseded or conflicting files produce outdated or inconsistent answers.
• ✓ On paid plans, large knowledge is searched with RAG, which ranks by relevance rather than approval, so curation matters just as much.
• ✓ Test with a few representative questions whose answers you know before rollout, and fix failures in the configuration, not in one chat.
• ✓ On Team and Enterprise plans, share with Can view for users and Can edit for the few who maintain the sources; every member sees the instructions and knowledge.

Check your understanding

4 questions written for this lesson, then one from the CCAO-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• What are projects?
• How can I create and manage projects?
• Retrieval augmented generation (RAG) for projects
• Introduction to projects (Claude 101)
• Plans and pricing
• Effective context engineering for AI agents
• The CCAO-F exam guide, summarised