CCAR-P Domain 7: Developer Productivity & Operational Enablement

Claude Code resolves configuration in layers. User settings (~/.claude/settings.json) apply to one engineer everywhere; project settings (.claude/settings.json, checked into the repo) apply to everyone on that repo; local settings (.claude/settings.local.json, gitignored) let an individual override without polluting the shared config. Enterprise-managed policy settings sit above all of them and cannot be overridden. As an architect you push team defaults into the checked-in project layer and reserve the local layer for personal preference.

The harder design decision is which mechanism to use for a given rule. Some mechanisms advise the model; others are enforced by the harness before the model's output ever runs. Getting this mapping right is the core competency the domain tests.

Two complementary primitives turn tribal knowledge into reusable tooling. Custom slash commands are Markdown files in .claude/commands/ (project) or ~/.claude/commands/ (personal); the filename becomes the command, and the body is a prompt template that can take arguments. Skills are richer, model-invoked capabilities under .claude/skills/<name>/SKILL.md — the model reads a Skill's description and decides on its own when to pull it in, so Skills carry a whole procedure plus optional scripts and references.

• Reach for a slash command when a human wants an explicit, on-demand entry point — /deploy-check, /open-pr, /triage.
• Reach for a Skill when you want Claude to recognize a situation and apply a standard procedure without being told each time.
• Both live in the repo, so distribution is just git — clone the repo and the whole team has them.
• Version them like code: review changes in PRs, because a bad shared command misfires for everyone.

Non-interactive mode (-p / --print) is how Claude Code runs inside pipelines. In print mode you get a single answer and exit; combine it with structured output and hard limits so a CI step is deterministic, parseable, and cost-bounded. The flags below are the ones an architect wires into a pipeline.

# CI step: classify a PR diff into a bounded, schema-checked JSON result
claude -p "Classify the risk of this diff" \
  --output-format json \
  --json-schema '{"type":"object","properties":{"risk":{"type":"string"}},"required":["risk"]}' \
  --max-budget-usd 0.50 \
  --permission-mode plan \
  --allowedTools "Read Grep"

MCP servers extend Claude Code with tools — a database client, an internal ticketing API, a docs search. To distribute one across a team, define it at project scope in a checked-in .mcp.json at the repo root. Everyone who clones the repo inherits the same server definitions, so tool availability is reproducible rather than something each engineer configures by hand. User-scoped MCP config stays personal; local scope is for one-off experiments.

Secrets are the sharp edge. The .mcp.json you commit must never contain credentials. Reference environment variables with ${VAR} expansion and let each developer or CI runner supply the actual secret out of band — a secrets manager, CI variables, or a gitignored .env. The committed file describes how to connect; it never carries the key.

{
  "mcpServers": {
    "internal-tickets": {
      "command": "npx",
      "args": ["-y", "@acme/tickets-mcp"],
      "env": { "TICKETS_API_TOKEN": "${TICKETS_API_TOKEN}" }
    }
  }
}

The payoff of committing CLAUDE.md, .claude/commands/, .claude/skills/, .claude/settings.json, and .mcp.json to the repo is that a new hire's first git clone brings the entire operational context with it — conventions, team commands, standard procedures, permission guardrails, and tool wiring. That is the golden path: the sanctioned, low-friction route that is easier to take than to reinvent.

• Ship starter templates (repo scaffolds) that already contain the .claude/ config so new services inherit the standard from day one.
• Keep secrets out of every committed file; document the required env vars in CLAUDE.md so onboarding is self-serve.
• Treat the shared config as reviewed code — changes go through PRs, not ad hoc edits to one person's machine.
• Use enterprise-managed policy settings for controls that must not be locally overridable across the org.

Enablement without measurement is faith. An architect instruments adoption and outcomes, then feeds the data back into the shared config. Structured JSON output from headless runs, session cost data, and standard delivery signals (cycle time, review turnaround, change-failure rate) let you see whether the golden path is actually being taken and whether it helps.

• Adoption: are the shared commands, Skills, and MCP servers actually invoked, or do engineers route around them?
• Cost: --max-budget-usd and JSON output make per-run spend observable so automation stays within budget.
• Flow: measure delivery outcomes (lead time, defect escape rate), not vanity metrics like lines generated.
• Feedback loop: when a control is repeatedly overridden, that is a signal the guidance is wrong — fix the config, not the people.