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.