Claude Certified Engineers logoCCE

CCAR-P · Study Guide

← Domain 7: Developer Productivity & Operational Enablement

7.1 · Lesson 1 of 3

Configure Claude tools and environments for teams (e.g., Claude Code)

What You Need to Know

Configuring Claude tools for teams — Claude Code, shared skills, and MCP — means making project-scoped shared config the source of truth. Rules, skills, and approved MCP servers live in the repo so every engineer inherits the same standards on clone. Personal config may hold preferences; it must not stand in for team standards.

Secrets stay out of version control and shell history. New teammates need a documented bootstrap: install, fetch secrets safely, verify, and start. Rollouts that leave everyone with personal MCP tokens in history and no shared project config fail Team Claude Code Rollout–style stems. The architect’s job is consistency and hygiene — not a pile of one-offs.

Team config surfaces

  • Project-scoped rules and instructions checked into the repo
  • Shared agent skills the team agrees to maintain
  • Approved MCP servers with env-based credentials
  • Secret hygiene: vault/CI secrets, never VCS or paste history
  • Bootstrap docs that a stranger can follow without Slack archaeology

Decision rules

  • Prefer project-scoped shared config over personal-only setup.
  • Keep secrets out of VCS and shell history.
  • Document bootstrap so new teammates inherit standards on clone.
  • Name owners for shared rules, skills, and MCP surfaces.
  • Treat personal config as preference — never as the team standard.

Shared config vs personal preference

Shared: anything that changes how the agent behaves for the product or how tools are authorized (rules, skills, MCP allowlists). Personal: UI chrome and individual shortcuts. When onboarding requires reading someone’s home directory to “get Claude working,” the rollout has failed the team-config bar.

Review checklist

  • Are rules, skills, and MCP definitions project-scoped in the repo?
  • Are secrets only in env/vault — not git, history, or prompts?
  • Is there a written bootstrap with a verify step?
  • Does each shared surface have an owner?
  • Would a new hire succeed without tribal personal config?

Stems that celebrate personal-only MCP tokens or “everyone figures it out” reward naming the tribal-config trap and returning to shared project standards.

Exam application

Prefer answers that install project-scoped config, secret hygiene, and documented bootstrap. Distractors: personal-only standards, keys in git, ban tools without a shared alternative, or treating Claude Code as unmanaged preference.

Exam traps

  • Personal config standing in for team standards

    Tribal ~/.config setups diverge, leak secrets, and break onboarding. Exam stems (Team Claude Code Rollout) reward project-scoped shared rules, skills, and MCP.

  • Secrets in VCS or shell history

    API keys and MCP tokens in git or paste history become incident fuel. Use env/secret managers and redact from logs.

  • Skipping bootstrap docs

    Without a clone → install → verify path, every hire reinvents setup and silently drifts from the standard.

  • Treating Claude Code as optional personal preference only

    If the org standardizes tooling, architects own shared project config and safe defaults — not a free-for-all of one-offs.

Practice scenario

Engineering is rolling out Claude Code. Each developer keeps personal MCP tokens in shell history, and the repo has no shared project rules or skills. New hires rebuild setup from Slack lore. What is the architect’s best default stance?

Choose one answer

Build exercise

Stand up a team Claude Code standard for an engineering org

35 minutes

What you'll learn

  • Separate project-scoped config from personal preference
  • Enforce secret hygiene for MCP and API credentials
  • Publish shared rules, skills, and MCP allowlists
  • Document and dry-run a new-hire bootstrap

  1. Step 1

    Inventory what must be shared vs personal

    List rules, skills, MCP servers, and ignore patterns that belong in the repo. Keep editor preferences personal; keep team standards project-scoped.

    Why: Shared config is the unit of team consistency. Personal-only standards fail onboarding and audits.

    You should see: A two-column table: project-scoped vs personal-only.

  2. Step 2

    Establish secret hygiene

    Route credentials through env vars or a secret manager. Ban keys in shell history examples, committed .env files, and prompt paste demos.

    Why: Secret leaks dominate Claude Code rollout incidents in exam scenarios.

    You should see: A secrets checklist checked into the bootstrap doc (how to fetch, where to put, what never to commit).

  3. Step 3

    Publish project-scoped rules, skills, and MCP

    Check in shared rules and skills, define approved MCP servers with least privilege, and document how they attach for the team.

    Why: New teammates inherit standards on clone instead of rebuilding tribal setup.

    You should see: Repo paths for rules/skills + an MCP allowlist with owners.

  4. Step 4

    Write the bootstrap for new teammates

    Document install, auth, verify (smoke commands), and who to ask. Run the path with a new-hire dry run.

    Why: Documented bootstrap is the exam’s positive signal that personal config is not the team standard.

    You should see: A one-page README section: prerequisites → clone → secrets → verify → first task.

Sources