Scenario 4: Developer Productivity Tools

The problem

A 40-engineer platform team wants Claude to become a reliable teammate inside their monorepo. Today every engineer pastes code into a chat window, copies answers back, and re-explains the same conventions in every session. Reviews are slow, generated code ignores the team's lint rules, and nobody can run the assistant in CI. Leadership asks for a single architecture that gives consistent behavior across three surfaces: an individual workstation, a shared repository, and a non-interactive pipeline. This scenario is squarely about Domain 3 (Claude Code configuration & workflows) and Domain 2 (tool design & MCP integration) — turning an ad-hoc chatbot into governed, tool-equipped developer tooling.

The right architecture

Start with layered memory, not prompts. Claude Code loads CLAUDE.md from multiple locations and merges them, broadest to most specific: enterprise/managed policy, project ./CLAUDE.md (committed, shared via git), directory-level CLAUDE.md in subtrees, user ~/.claude/CLAUDE.md, and local ./CLAUDE.local.md (gitignored). Conventions everyone must follow live in the committed project file; personal preferences stay in user memory. Keep the root file short and declarative, pull deep docs in with @path imports, and prefer rules a linter or test can mechanically enforce over prose.

Next, package repeatable work as custom slash commands and Skills instead of re-typing instructions. A /review command in .claude/commands/ can carry an argument-hint, an allowed-tools list, and run in a forked context so it does not pollute the main thread. Skills bundle reusable procedures the model loads on demand. For team-wide tasks (open-a-PR, run-migrations, triage-flaky-test), commit these to the repo so every engineer and the CI runner share the same behavior.

Then give the agent well-designed tools. The platform team exposes internal capabilities — querying the deploy registry, fetching CI logs, reading the design-system catalog — as an MCP server. Configure it in .mcp.json (committed, project-scoped) rather than ~/.claude.json (personal), so discovery is identical for humans and pipelines. Put secrets in environment variables referenced by the config, never inline. For a local toolserver use the stdio transport; for a shared internal service use SSE/HTTP behind authentication.

Tool descriptions are the selection mechanism: write them as the spec the model reads to decide what to call. Avoid overlapping tools (getLogs vs fetchLogs) that create ambiguity. Return structured errors with isError set and a type the model can act on — transient (retry), validation (fix arguments), or permission (stop and surface). Use tool_choice deliberately: auto for exploratory help, any/forced when a step must call exactly one tool (for example, always log an audit event).

Key decisions

• Permissions and plan mode. For risky surfaces (production scripts, schema changes) require plan mode so the engineer approves a plan before edits. Encode a permission model — allow read/grep freely, gate writes and shell on confirmation.
• Headless for CI. Run the same assistant non-interactively with claude -p "..." --output-format json and consume the structured result in a pipeline step. A --json-schema constrains output so the build can branch on it deterministically.
• Context hygiene. Long sessions degrade; use /compact, /memory, and an Explore subagent to keep the working context focused on the current task.

Common traps

• Stuffing everything into one giant CLAUDE.md. It bloats context and buries the rules that matter. Keep it a ~100-line map; import the rest.
• Personal MCP config for a shared workflow. Putting servers in ~/.claude.json means CI and new teammates silently lack the tools. Commit .mcp.json.
• Free-text tool errors. Returning a raw stack trace as success text gives the model nothing to recover from; emit isError plus an error type.
• Forcing tool_choice everywhere. Forcing a tool when the right move is to answer directly breaks normal conversation. Reserve forced choice for steps that genuinely must call a tool.
• Secrets inline. Hard-coded tokens in committed config leak; reference env vars.

How it maps to the exam

This scenario blends two domains. Domain 2 questions probe whether you can design tools the model selects reliably, return structured errors, and integrate MCP end to end (config location, transport choice, secrets). Domain 3 questions probe the CLAUDE.md hierarchy and precedence, slash commands versus Skills, permission/plan-mode choices, and headless CI runs. When a stem describes a team standardizing an AI workflow, ask: which layer owns this configuration, and is this a tool-design problem or a Claude Code configuration problem? The strongest answers put shared rules in committed project files, expose internal systems through a project-scoped MCP server with structured errors, and make the workflow runnable headlessly so it works the same on a laptop and in CI.