Domain 5 — Configuration and Knowledge Management

CCA Associate Foundations course · Page 6 of 10 · ← Back to all courses · Weight: 12%. Mark this page complete at the bottom to advance your course progress.

5.1 — The CLAUDE.md Hierarchy · Core

The hierarchy accumulates — it never replaces. All applicable levels load simultaneously; the more-specific directory file adds on top, it doesn't discard the project-level file. Run /memory to see exactly which files are currently active — the correct first diagnostic step whenever behavior is inconsistent, before deleting or rewriting anything.

⚠ Often-missed — The Classic Sharing Mistake · Gap

A developer writes team standards into ~/.claude/CLAUDE.md. A teammate clones the repo and gets nothing — user-level config never travels with the repository. Team-wide rules always belong in project-level .claude/CLAUDE.md, committed to the repo. This is the single most-tested distinction in this domain.

5.2 — Commands, Skills, and Path-Scoped Rules · Core

• Commands (.claude/commands/ = team-wide, committed; ~/.claude/commands/ = personal). Same name in both scopes → the user-scoped version wins for that developer only, without touching the shared file.
• Skills (SKILL.md frontmatter): context: fork runs the skill in an isolated sub-agent so its verbose output doesn't pollute the main conversation; allowed-tools restricts which tools a skill may call (e.g., [Read, Grep, Glob] for a guaranteed read-only skill); argument-hint prompts for a required parameter when the skill runs without one.
• Path-scoped rules (.claude/rules/*.md with paths: frontmatter) apply a convention to files scattered across the codebase by type, regardless of directory — **/*.test.tsx matches at any depth; without the double star it only matches the root.

5.3 — MCP Connectors, Secrets, and Skill Distribution · Core

MCP server configuration is committed to .claude/settings.json — every teammate gets it on checkout. The API key itself is never committed: reference it as ${DW_API_KEY} and let each developer set the real value in their own environment. A raw credential in a committed file is always the wrong answer.

5.4 — Maintaining Instructions and Rolling Out to a Team · Core

Keep a large CLAUDE.md maintainable by splitting it into focused files under .claude/rules/ and pulling them in with @import — one concern per file, updated once, applied everywhere it's imported.

Champion-then-batch rollout: one champion per department gets early access, proves a real workflow in about two weeks, runs a 45-minute session for their first batch of peers, and becomes first-line support. Broad rollout only follows once every department has a working example and a local expert — this prevents one architect from being the sole contact for every question, company-wide.

5.5 — Permissions and Spend Controls · Core

Least privilege in CI and shared environments: a code-review bot needs read access to the files it reviews and write access to post PR comments — nothing more. No production database writes, no admin access "to avoid failures" (that inverts least privilege rather than applying it).

Spend controls an admin sets deliberately rather than inheriting defaults: which model a session starts on, allowlists/restrictions on which models a team may escalate to, effort guidance, and per-user caps — the specific control that stops a handful of high-usage developers from exhausting a shared team budget before everyone else gets a turn.

Exam reflexes for Domain 5

• Team standard written in ~/.claude/CLAUDE.md → teammates never receive it; must be project-level.
• Behavior inconsistent across sessions → run /memory first, before deleting or rewriting anything.
• Skill needs a hard read-only guarantee → allowed-tools: [Read, Grep, Glob], not a description or fork.
• Committed settings file contains a raw API key → always wrong; use ${VAR_NAME} instead.
• Bad update shipped to everyone with no rollback → org-provisioned Skill (no version pinning); plugin-to-group is the governed alternative.
• Rollout to 200 people planned as one simultaneous launch → wrong; champion-then-batch prevents overload.
• CI job requesting broad or admin permissions "to avoid errors" → wrong; grant only what the job needs.
• A few developers risk exhausting the team's Claude budget → per-user spend caps.