Developer Productivity & Operational Enablement
7% of examConfigure Claude Code and related tooling for teams, raise developer productivity with disciplined AI-assisted workflows, and localize and resolve operational issues in Claude-powered systems.
3
task statements
8
concepts
24
practice questions
Domain Mastery
Configure Claude tools and environments for teams
Standardizing CLAUDE.md hierarchy and settings.json as separate control surfaces, and distributing shared MCP servers and team-wide Skills so every developer gets consistent, safe behavior.
Knowledge of
- The CLAUDE.md hierarchy: enterprise/system, user (~/.claude), project (./CLAUDE.md), and subdirectory levels, auto-loaded into context, with the project-level CLAUDE.md committed to the repo so the whole team shares the same conventions
- settings.json as the deterministic control surface for tool allow/deny lists, hooks, environment variables, model selection, and connected MCP servers -- distinct from CLAUDE.md's memory/instructions role
- Shared MCP servers as build-once, reuse-across-the-team configuration for common integrations (internal APIs, data sources)
- Team-wide Skills distribution via repos, plugins, or enterprise managed settings so procedures and know-how are shared rather than reinvented per developer
Skills in
- Diagnosing a misconfiguration where permissions or tool allow/deny rules were mistakenly placed in CLAUDE.md instead of settings.json
- Standardizing team-wide Claude Code behavior by committing a project-level CLAUDE.md to the repo rather than relying on each developer's personal configuration
- Configuring a shared MCP server once for a common integration instead of having every developer configure the same integration individually
- Distributing reusable Skills via repos, plugins, or enterprise managed settings so know-how is shared team-wide
Concepts
CLAUDE.md vs settings.json for Team Configuration
✎CoreCLAUDE.md is memory/instructions; settings.json is deterministic configuration (permissions, hooks, MCP)
Shared MCP Servers & Team-Wide Skills Distribution
✎CoreConfigure common integrations once as shared MCP servers so every developer's Claude Code reaches the same capabilities
Champion-Per-Department Rollout: Adoption as an Architecture Problem
✎CoreDesignate one champion per department/team who gets deep onboarding first, then runs peer-to-peer adoption sessions for their own team in small batches
Spend Posture Controls: Governing Organizational AI Spend
✎CoreSpend posture is governed by four levers: model defaults, model allowlists/restrictions, effort/reasoning-depth guidance, and spend/rate/per-user caps
Improve developer workflows with AI-assisted tooling
Applying the gather-context, plan, act, verify loop and extending AI assistance into CI/CD pipelines and custom internal agents via the Agent SDK and headless mode, without sacrificing verification.
Knowledge of
- The gather-context to plan to act to verify loop as Claude Code's core best-practice workflow, keeping context lean to avoid context rot
- The Agent SDK enabling teams to build custom internal agents and automate workflows beyond the interactive tool (CI/CD checks, codebase modernization, repetitive engineering tasks)
- Headless/non-interactive modes for running Claude Code in scripts and CI pipelines
- Custom slash commands and automation (e.g., GitHub integration) for standardizing common team tasks
Skills in
- Structuring an AI-assisted workflow around gather-context, plan, act, verify rather than skipping the verify step for speed
- Keeping context lean during iterative work to avoid context rot degrading output quality
- Using the Agent SDK to build custom internal agents for CI/CD automation and repetitive engineering tasks
- Running Claude Code in headless/non-interactive mode to extend AI assistance into CI pipelines
- Standardizing common team tasks with custom slash commands and GitHub integration automation
Concepts
The Gather-Context, Plan, Act, Verify Loop
✎CoreThe best-practice workflow is gather-context, plan, act, verify -- not a single unsupervised step
Programmatic Enablement: Agent SDK & Headless Mode
✓AdvancedThe Agent SDK enables building custom internal agents for CI/CD checks, codebase modernization, and repetitive engineering tasks
Support debugging and operational issue resolution
Localizing a Claude-powered system's misbehavior to the correct layer using traces and logs, checking operational basics, and feeding confirmed fixes back into evals and monitoring.
Knowledge of
- Isolating a failure to its originating layer -- transport (HTTP/auth errors), integration/parsing code, retrieval (stale/irrelevant chunks), or model output (well-formed but wrong) -- before applying a fix
- Using traces and logs (request/response pairs, tool calls, retrieval hits, stop_reason, token usage) to walk back to the earliest deviation rather than just the final symptom
- Checking operational basics: truncated output (stop_reason: max_tokens), model version mismatches, and context bloat late in a session
- Feeding confirmed fixes back into evals and monitoring so recurring issues are caught automatically next time
Skills in
- Localizing a production issue to the transport, integration/parsing, retrieval, or model-output layer before changing any code or prompts
- Tracing request/response pairs, tool calls, retrieval hits, stop_reason, and token usage back to the earliest point of deviation
- Diagnosing truncated output by checking for stop_reason: max_tokens and raising the max_tokens parameter rather than assuming a quality or security problem
- Recognizing model version mismatches and context bloat as operational root causes distinct from prompt or code defects
- Feeding confirmed fixes back into eval suites and monitoring dashboards to prevent the same issue from recurring
Concepts
Issue Isolation: Localizing Failures Across Layers
✎CoreIsolate a failure to transport, integration/parsing code, retrieval, or model output before applying any fix
Runbooks & Escalation Paths: Making Diagnosis Reusable
✎CoreA runbook maps symptom -> likely architecture cause -> first diagnostic action, built up from real incidents, so the second occurrence of a known issue is a five-minute lookup instead of a from-scratch investigation