Claude Certification Guide CCAO-F

Curriculum › Configuration and Knowledge Management · 12% of the exam

Setting up a Project: instructions and knowledge

What you’ll be able to do

  • Decide what goes into Project instructions and what goes into Project knowledge
  • Write clear standing instructions that apply to every chat in the Project
  • Curate knowledge files that are relevant, authoritative and current

What you need to know

Two parts with two jobs

A Project has two configuration pieces, and keeping their jobs separate is most of the skill.

  • Project instructions are standing guidance that applies to every chat in the Project. They tell Claude how to work: who it's helping, for what audience, in what tone and format, within what boundaries. These are the "system-level" instructions the exam guide refers to. In plain terms, they're the briefing you'd give a new colleague before they take on any task in this area.
  • Project knowledge is the reference material Claude works from: uploaded files such as a style guide, policy handbook, product sheet, past reports or a glossary.

A simple test: if it's a rule about behavior, it goes in instructions. If it's content to look things up in, it goes in knowledge. Pasting a forty-page handbook into the instructions buries the actual rules. Leaving "always answer in British English" in a buried file means it may not get applied.

Writing effective Project instructions

Good instructions are short enough to read in a minute and specific enough to change behavior. Cover these elements:

  • Role and purpose: "You help the HR team answer employee questions about leave and benefits."
  • Audience: "Answers go to employees with no HR background. Use plain language."
  • Format and tone: "Lead with the direct answer, then the relevant policy section, then next steps. Friendly but neutral."
  • Sources and grounding: "Base answers on the uploaded policy documents. If the documents don't cover the question, say so rather than guessing."
  • Boundaries and escalation: "Don't give legal advice or decide individual cases. For disputes, accommodations or anything not covered, direct the person to the HR inbox."
Before
This project is about our company's HR policies.
After
You draft answers to employee leave and benefits questions for HR to review. Use only the uploaded policies; if they don't cover it, say so. Plain language, direct answer first, cite the policy section. Refer disputes and individual cases to HR.

Keep task-specific details out of the instructions. "This week's question is about the new parental-leave change" belongs in a chat message, not in guidance that applies to every future chat.

Curating Project knowledge

More files is not better. Each file you add is something Claude may draw on, so an outdated or off-topic file is a source of wrong answers.

  • Relevant: include what the Project's tasks actually need. A brand-voice Project needs the voice guide and good examples, not the entire marketing drive.
  • Authoritative: prefer the official, approved version over someone's working notes.
  • Current and single-version: don't leave both "Leave Policy 2024" and "Leave Policy 2025" in place unless the instructions explain which wins. Conflicting versions produce inconsistent answers.
  • Clearly named: descriptive file names help you, your teammates and Claude tell documents apart. "Travel-Policy-approved-current" beats "final_v3_NEW".
  • Appropriate to share: check data sensitivity before uploading, especially if the Project is shared with others (Domain 6). Remove or anonymize regulated personal data first.

You can point to specific files in instructions, for example: "For pricing questions, use the current price sheet; treat the archived files as background only."

Test before you share

Before you roll a Project out to a team, try it with five to ten realistic requests, including awkward ones: a question the documents don't cover, a request outside the Project's scope, a question where two documents seem to disagree. Check that answers follow the format, stay grounded in the files, and decline or escalate where they should. Adjust the instructions or the files, then test again. A shared Project's mistakes repeat for everyone who uses it, so a few minutes of testing pays off.

Some configurations go beyond what a Project can sensibly do, such as automated pipelines, integrations with internal systems, or strict guarantees about outputs. That is the point to escalate to Claude Developers or Architects rather than stretching the Project's instructions.

Key concept

Project instructions tell Claude how to behave in every chat; Project knowledge gives it what to work from. Keep instructions short and behavioral, and keep knowledge relevant, authoritative and current.

Exam questions often show a Project giving inconsistent or off-target answers. Diagnose it as an instructions problem (missing audience, format, boundaries or grounding rules) or a knowledge problem (outdated, conflicting or irrelevant files), and pick the fix that targets that cause.

Practice scenario

ScenarioA training manager sets up a Project to help team leads write onboarding plans. The instructions say only "Onboarding project." He uploads thirty files from the shared drive, including three versions of the onboarding checklist, old slide decks and a spreadsheet of new-hire names and start dates. Team leads say the plans vary wildly in format and sometimes reference steps that were dropped last year.
Work it through, then open this

Both parts of the configuration need work. The instructions give no role, audience, format or boundaries, so the inconsistent formats are no surprise. He should write standing instructions covering who the plans are for, the required structure, the rule to use only the current checklist, and what to do when something isn’t covered. The knowledge has conflicting versions and outdated decks, which explains the dropped steps. He should keep only the current checklist and the material the task actually needs. The new-hire spreadsheet doesn’t belong there at all: it’s personal data the task doesn’t require. Then he should test with a few real requests before team leads rely on the Project again.

Hands-on exercise — Build and test a small Project

Beginner · 15 min

What you’ll learn

  • Writing behavioral Project instructions
  • Choosing a small, clean knowledge set
  • Testing with realistic and awkward requests

  1. Create a Project for one recurring task you do. Write instructions covering role, audience, format, sources and boundaries in five or six sentences.

    • Why: These elements are what change behavior across every chat in the Project.
    • You should see: Instructions you could read aloud in under a minute that someone new could follow.

  2. Upload two or three files: the single current, authoritative version of each reference you need, with clear names and no sensitive personal data.

    • Why: A small, clean knowledge set reduces conflicting or outdated answers.
    • You should see: A short list of files where each one has an obvious reason to be there.

  3. Start a chat in the Project and send three requests: a normal one, one the files don’t cover, and one outside the Project’s scope.

    • Why: The edge cases show whether your grounding and boundary instructions actually work.
    • You should see: The normal request answered in your format, the uncovered one flagged rather than guessed, and the out-of-scope one redirected. If not, revise the instructions and test again.

Exam traps

Pasting entire reference documents into the Project instructions

Instructions should be short behavioral guidance. Reference material belongs in Project knowledge, where it won’t bury the rules.

Uploading every loosely related file in case it helps

Irrelevant or outdated files give Claude more chances to draw on the wrong source. Curate for relevance and authority.

Writing instructions that only describe the topic, not how to behave

“This project is about X” changes little. Say who the output is for, the format and tone, which sources to use and when to escalate.

Leaving conflicting versions of the same document in Project knowledge

Two versions of a policy lead to inconsistent answers. Keep the current one, or state in the instructions which one wins.

Putting one-off task details into instructions that apply to every chat

Instructions apply to every chat in the Project. This week’s specifics belong in the chat message.

Sharing a Project with the team before testing it on real requests

A shared Project’s flaws repeat for everyone. Test with normal, uncovered and out-of-scope requests first.

Sources

Quick check

Select TWO.

A legal operations coordinator is preparing Project knowledge for a contract-question assistant that colleagues will share. Select the two actions that best reflect good knowledge curation.