Domain 5: Configuration and Knowledge Management
12% of examConfigure Claude Projects for persistent, reusable work
Key Points
- A Project bundles instructions (standing role/tone/format/rules) and project knowledge (uploaded reference material), both persisting across every conversation in the Project.
- Projects fit recurring, knowledge-heavy work: a client account, a product line, a repeated report -- configure once, reuse many times.
- When project knowledge is large, Claude retrieves relevant portions rather than reading everything, which is how a Project scales beyond a single context window.
- Retrieval solves the 'too much to fit' problem; it does not solve the 'this file is stale/irrelevant' problem -- that still needs active curation.
- Repeatedly pasting the same context into new chats is the classic exam trap; the fix is a Project, not a bigger model.
Decision Rules
When: A team repeatedly pastes the same brand guide/FAQ into new chats
→Add them as Project instructions/knowledge instead.
When: Project knowledge grows large
→Trust retrieval to surface relevant portions, but still curate out stale or irrelevant files.
When: A task is recurring and knowledge-heavy (a client account, a product line)
→Set it up as a Project rather than a one-off chat.
✗ Anti-Patterns to Reject
- Pasting the same context into each new chat instead of putting it in the Project once.
- Assuming a more capable model, rather than a Project, fixes repeated-context pasting.
Manage uploaded knowledge and connectors
Key Points
- Uploads are files added directly (a static snapshot); connectors are integrations to a live external source (Google Drive, Gmail).
- Connector and feature availability is plan/pricing-tier dependent, not universal.
- Curate knowledge actively: add sources that matter, keep them organized, remove/update stale material -- applies to uploads and to connected sources alike.
- Knowledge management overlaps with governance: uploading or connecting sensitive/regulated data without checking policy first is a governance failure, not just a technical choice.
Decision Rules
When: Deciding whether a connector like Google Drive or Gmail is available
→Check the plan/pricing tier rather than assuming it's universally available.
When: About to upload or connect a data source
→Check it against data-handling policy before adding it as knowledge, not just for convenience.
When: A Project's knowledge base is accumulating files
→Actively remove or update stale material rather than letting it pile up alongside current versions.
✗ Anti-Patterns to Reject
- Assuming all connectors are available on every plan.
- Uploading or connecting regulated/sensitive data without checking policy first.
Write effective system-level instructions
Key Points
- Effective Project instructions are specific about role/goal, explicit about format/tone, clear on boundaries, and concise/high-signal.
- This is the same prompting discipline as Domain 1, applied at workspace scope so it governs every conversation automatically.
- Agent Skills are the same idea (reusable, packaged instructions) applied to a specific recurring task rather than a whole workspace.
- Vague instructions ('be helpful') don't constrain behavior; overloaded, detail-heavy instructions bury the rules that matter.
Decision Rules
When: Writing Project instructions
→Specify role, format, tone, and boundaries explicitly and concisely -- don't just say 'be helpful.'
When: Instructions have grown long and detailed
→Trim to the high-signal rules that actually matter rather than letting them get buried.
When: A recurring task keeps needing the same instructions re-explained
→Consider packaging it as an Agent Skill.
✗ Anti-Patterns to Reject
- Writing vague instructions ('be helpful and smart') that don't actually constrain behavior.
- Overloading instructions with so much detail that the key rules get buried.
Maintain and update configurations over time
Key Points
- Configuration is not 'set and forget' -- business context and source material change.
- Refresh knowledge sources when documents change and remove superseded versions; update instructions when process/tone/rules change; review periodically against how the team actually works.
- Stale configuration is a quiet failure mode: Claude faithfully follows outdated instructions or cites old policy with no error signal.
- Keeping knowledge/instructions current is itself an accuracy control, not just housekeeping.
Decision Rules
When: A policy document in a Project is replaced by a new version
→Update/replace the source so Claude grounds answers in the current policy -- don't keep both 'for completeness.'
When: A process, tone, or rule changes
→Update the Project instructions promptly rather than leaving them as originally set.
When: A Project was configured well a while ago
→Periodically review it against current practice rather than assuming it stays correct indefinitely.
✗ Anti-Patterns to Reject
- Leaving outdated documents in a Project so Claude grounds answers in superseded material.
- Assuming a one-time setup stays correct indefinitely as the process evolves.