Build & submit taskBetabeginner

Configure a Claude Project and Prove the Configuration Changed the Output

Build a working Claude Project for a real recurring job: write system-level instructions, curate the knowledge sources deliberately including what you excluded and why, then run one identical prompt inside and outside the Project and paste both outputs so the configuration is proven to have landed. Closes with a maintenance plan for keeping it from going stale. No coding required.

2 hrs

Est. time

Outcomes

Rubric criteria

65%

Pass score

What you'll learn

Skills you'll have real reps in after shipping this.

Configuration has to be tested

Instructions are guidance the model reads rather than a switch that flips. Running the same prompt inside and outside the Project is what tells you whether your instructions reached the output at all.

Exclusion is the harder half of curation

Uploading everything available buries the material that matters and drags in documents nobody vetted. What you left out, and why, says more about the configuration than what you put in.

Two instructions earn their place immediately

Telling Claude what format to produce and what to do when it lacks the information to answer prevents the two failure modes that cause the most rework.

Sensitivity is checked before upload

Knowledge sources are a place where personal or confidential material enters a shared surface. That check belongs in the configuration process rather than in an incident review.

Unowned configuration goes stale silently

A Project keeps producing plausible output long after its instructions stopped matching reality, so a named owner and a review cadence are part of the build.

See how it works

What persists across conversations

Summary-buffer window

130 / 120 tok

budget

120 tok

system 📌You are a helpful project assistant.20

summary of 4 older turns≈24 tok

Dana (Acme) is migrating to Postgres by the Helsinki deadline, budget 8000; Carlos flagged clause 12.

userCarlos from legal flagged clause 12.34

assistantUnderstood, clause 12 is a risk.22

userWhat did we decide on the database?30

Keep recent, summarize the rest. The system message is always pinned and the latest turns stay verbatim. As the budget tightens, the oldest turns fold into one faithful summary, facts preserved, tokens reclaimed.

Instructions and knowledge sources are the two things a Project carries into every conversation inside it. Running the same prompt inside and outside is the cheapest way to see whether either one is actually reaching the output.

The scenario

Most Claude Projects are set up once, filled with whatever documents were handy, and never touched again. Six months later the instructions describe a process that changed, two of the uploaded files are superseded, and nobody notices because the output still reads fine. A Project is configuration, and configuration that nobody maintains quietly becomes a source of confidently wrong answers.

A Project holds two things that persist across every conversation inside it: instructions that shape how Claude behaves, and knowledge sources it can draw on. Both are curation problems. Instructions that restate the obvious change nothing, and instructions that conflict with each other produce unpredictable behavior. Knowledge that includes everything available buries the relevant material, and knowledge that includes sensitive material creates a problem that has nothing to do with output quality. This task makes you configure a Project for a job you actually have, then check mechanically that the configuration reached the model by running one identical prompt inside and outside the Project and comparing what came back.

Your role

You are the person who sets up shared Claude configuration for your team. Your deliverable is a documented Project configuration, a controlled comparison proving the instructions and knowledge took effect, and a maintenance plan that says who keeps it current and when.

Start the task to unlock the full brief

You'll get the step-by-step requirements, setup commands, the 9-criterion grading rubric, tips, and the ability to submit your solution for instant AI grading.

Free to start · submit when you're ready

Learning resources

Anthropic Help Center: Projects

Instructions and knowledge that persist across conversations.

support.anthropic.com

Anthropic: system prompts

How system-level instruction shapes behavior.

docs.anthropic.com

Anthropic privacy center

How data you provide is handled, for the sensitivity check.

anthropic.com

What you'll build in this Claude Projects configuration task

This is a build-and-submit task rather than a guided lab, and it requires no coding. You configure a real Claude Project for a recurring job you actually have: system-level instructions written to change behavior rather than restate defaults, and a knowledge-source inventory that records what you deliberately left out alongside what you included, with the data-sensitivity check you ran before uploading anything.

The part that makes it verifiable is the controlled comparison. You run one identical prompt inside the Project and outside it, paste both verbatim outputs, and name the specific differences, tracing each back to the instruction or knowledge source responsible. Instructions are guidance the model reads rather than a switch that flips, which is exactly why you test that they landed. At least one instruction has to be revised and retested after the comparison shows it was not reaching the output.

Grading is rubric-based and explainable. Your submission is scored against weighted criteria covering instruction quality, knowledge curation and exclusions, the sensitivity check, the controlled comparison, and the maintenance plan, with per-criterion feedback quoted from your document. The pass threshold is 65 percent and you can resubmit. Configuration and knowledge management is a scored domain on the Claude Certified Associate Foundations exam.

Frequently asked questions

Do I need a paid Claude plan?

You need a claude.ai plan that includes Projects, since the task turns on configuring one and comparing behavior inside and outside it. No API key, terminal, or coding is involved, and the deliverable is a Markdown or PDF document.

Why run the same prompt inside and outside the Project?

Instructions are guidance the model reads rather than a setting that mechanically enforces itself, so the only way to know yours are doing anything is to hold the prompt constant and change only whether the Project configuration is present. Differences between the two outputs are your evidence.

What if both outputs come back nearly identical?

That is a real finding and the rubric expects you to act on it. Revise the instruction that failed to land, make it more specific, retest, and paste the result. A comparison that showed nothing followed by a diagnosed fix scores better than a comparison you did not run.

Why does the task care what I excluded from the knowledge sources?

Uploading everything to hand buries the relevant material and pulls in documents nobody vetted. Exclusion is where the judgment lives, and it is also where data-sensitivity decisions get made, which the certification treats as part of responsible configuration.

What counts as a complete submission?

One Markdown, text, or PDF file stating the Project's job and users, the full instruction text with per-instruction reasoning including format and missing-information rules, a knowledge inventory with justified exclusions and a sensitivity check, an identical-prompt comparison with both verbatim outputs and attributed differences, one revised and retested instruction, and a maintenance plan with owner, cadence, staleness signals, and update procedure.