# D7 · Developer Productivity & Operational Enablement

Configuring Claude tooling for teams (managed policies, checked-in settings, CLAUDE.md, shared Skills/commands/subagents, MCP catalogues), AI-assisted workflows, operational support, productivity measurement, and safe-adoption enablement.

import { Accordions, AccordionItem, Tabs, TabItem, Steps } from '@prosefly/astro-components';

This is the smallest domain – **7%, roughly 4 of 63 items** – but it is high-yield because the answers are concrete. It tests whether you can **configure Claude Code for a team** (not just yourself), wire AI into developer workflows and CI, support operations, measure productivity, and run a **safe-adoption enablement programme** with guardrails. Correct answers favour **checked-in, managed, least-privilege** configuration over per-developer ad-hoc setup.

## Learning objectives

By the end of this page you should be able to:

1. Configure Claude tooling for **teams**: managed policies, checked-in `settings.json`, the CLAUDE.md hierarchy, shared Skills/commands/subagents, MCP server catalogues.
2. Improve workflows with **AI-assisted tooling**: code review, test generation, migration, CI integration with **headless mode**.
3. Support **debugging and operations**: runbooks, trace analysis, cost dashboards.
4. **Measure** developer productivity meaningfully.
5. Run **enablement programmes** with guardrails for safe adoption.

---

## 7.1 Configuring Claude Code for teams

Individual configuration does not scale or govern. Teams need **shared, versioned, policy-enforced** configuration.

### The CLAUDE.md hierarchy and settings precedence

```text
Precedence (higher wins / composes down):
  1. enterprise / managed policy        (admin-controlled, not overridable)
  2. user       ~/.claude/CLAUDE.md      (personal, per-developer)
  3. project    ./CLAUDE.md              (checked in, team standard)
  4. subdirectory CLAUDE.md              (module-specific)
  CLAUDE.local.md = git-ignored personal overrides; @path imports pull in shared files
```

| Asset | Location | Team practice |
| --- | --- | --- |
| Coding standards / context | `./CLAUDE.md` (checked in) | Single source of team conventions; `@path` imports for shared docs |
| Permissions / hooks / env / model | `.claude/settings.json` (checked in) | `permissions.allow/deny/ask`; deny destructive commands by default |
| Managed policy | enterprise/managed | Enforce org-wide rules developers **cannot** override |
| Skills | `.claude/skills/<name>/SKILL.md` | Shared, progressively loaded capabilities |
| Slash commands | `.claude/commands/*.md` | Reusable prompts with `$ARGUMENTS` |
| Subagents | `.claude/agents/*.md` | Own system prompt, **tools allowlist**, model; isolated context |
| MCP servers | `.mcp.json` (project scope) | A vetted **catalogue**; scopes local/project/user |

:::tip[Exam signal]
"Standardise across the team / enforce a rule no one can override" → **managed policy** and **checked-in** `.claude/settings.json` + `./CLAUDE.md`, not per-developer files. "Personal, don't commit" → `CLAUDE.local.md` / `settings.local.json`.
:::

:::caution[Least privilege in team config]
Set `permissions.deny` for destructive or out-of-scope actions and keep subagent **tools allowlists** narrow (D3 least privilege). Secrets go in `env`/secret managers, never in CLAUDE.md (D5).
:::

### Managed-policy settings example (enterprise)

Managed policy is admin-controlled and **cannot be overridden** by user, project, or local files. Deploy it via your MDM/config-management to the managed settings path so it applies to every developer and every repo.

```json
{
  "model": "claude-opus-5",
  "permissions": {
    "allow": ["Read", "Grep", "Glob"],
    "ask": ["Edit", "WebFetch"],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(**/secrets/**)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "/opt/claude/hooks/policy-guard.sh" }
        ]
      }
    ]
  },
  "env": {
    "ANTHROPIC_MODEL": "claude-opus-5",
    "DISABLE_TELEMETRY": "false"
  }
}
```

Because this lives in managed policy, a developer's `settings.local.json` allowing `Bash(rm -rf:*)` has no effect — the managed `deny` wins.

### Shared Skills / commands / subagents catalogue layout

Check a shared catalogue into the repo so every developer inherits the same vetted assets:

```text
.claude/
├── settings.json                # team baseline: permissions, hooks, env, model
├── CLAUDE.md                    # team coding standards (@imports shared docs)
├── skills/
│   ├── api-docs/SKILL.md        # house style for API reference docs
│   ├── test-authoring/SKILL.md  # unit + edge-case test conventions
│   └── sql-review/SKILL.md      # query review checklist
├── commands/
│   ├── fix-issue.md             # /fix-issue <number>  (uses $ARGUMENTS)
│   ├── review-diff.md           # /review-diff
│   └── new-endpoint.md          # /new-endpoint <name>
├── agents/
│   ├── reviewer.md              # read-only, security+style, model: claude-opus-5
│   ├── migrator.md              # plan-mode migrations, narrow write scope
│   └── explorer.md              # read-only codebase Q&A
└── .mcp.json                    # project-scope vetted MCP server catalogue
```

:::tip[Exam signal]
'Every developer should get the same reviewer/skill/MCP set' → a **checked-in `.claude/` catalogue** (project scope), not per-developer installs. 'No one may override the security rule' → **managed policy**.
:::

---

## 7.2 AI-assisted developer workflows

| Workflow | How Claude Code helps | Mechanism |
| --- | --- | --- |
| Code review | Automated review pass on diffs | Subagent/slash command; CI headless mode |
| Test generation | Generate/extend unit and edge-case tests | Slash command; Skill |
| Migration | Large-scale refactors/version migrations | Plan mode → apply; subagents |
| Codebase exploration | Answer "where/why" questions | Built-in tools; read-only plan mode |
| CI integration | Non-interactive automation | **Headless** `claude -p "…" --output-format json\|stream-json` with `--allowedTools`, `--permission-mode` |

```bash
# Headless code-review step (non-interactive, restricted tools)
claude -p "Review the staged diff for security and style issues; output findings as JSON." \
  --output-format json \
  --allowedTools "Read,Grep" \
  --permission-mode plan
```

Use **plan mode** (Shift+Tab) for read-only exploration before making changes, and structured output (`--output-format json`) so CI can parse results and gate the build.

### CI code-review integration (headless Claude Code)

A GitHub Actions job that runs a headless, read-only review on every pull request and posts findings, gating the merge on high-severity issues:

```yaml
name: claude-code-review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Install Claude Code
        run: npm install -g @anthropic-ai/claude-code
      - name: Review staged diff
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/diff.patch
          claude -p "Review /tmp/diff.patch for security and style issues. Output JSON: {'findings':[{'severity','file','note'}]}." \
            --output-format json \
            --allowedTools "Read,Grep" \
            --permission-mode plan > review.json
      - name: Fail on high-severity findings
        run: |
          if jq -e '.findings[] | select(.severity=="high")' review.json > /dev/null; then
            echo "High-severity findings present"; exit 1
          fi
```

Note the least-privilege posture: read-only tools, plan mode, structured output the pipeline can parse and gate on.

---

## 7.3 Operational support: runbooks and trace analysis

| Need | Enablement asset |
| --- | --- |
| Recover from incidents | **Runbooks** (D6) with rollback and on-call steps |
| Diagnose failures | **Trace analysis** via correlation IDs and span trees (D3) |
| Control spend | **Cost dashboards**; `/cost` in Claude Code; token/cost telemetry per team |
| Repeatable ops tasks | Shared slash commands and Skills for common fixes |

AI-assisted operations still respect the guardrails from D5: human approval on irreversible actions, least-privilege tools, secrets out of context.

### A runbook / trace-analysis flow

When a Claude-backed feature misbehaves in production, the runbook drives a repeatable diagnosis:

```text
1. Capture   → pull correlation_id from the alert; gather request_ids for the session
2. Classify  → integration vs model-output? read HTTP status + stop_reason
                 429/5xx/timeout/JSON  → integration (backoff, timeouts, request fix)
                 hallucination/drift/refusal/max_tokens → model output (prompt/model/validation)
3. Trace     → walk the tool sequence per step; look for repeated calls (loop),
                 climbing token usage, or a missing tool result
4. Reproduce → pin model snapshot, temperature 0, frozen system prompt, replay messages
5. Mitigate  → runbook action (rollback prompt/model version, raise limit, add validation)
                 irreversible action? require human approval
6. Verify    → re-run the golden set / per-segment eval before closing
```

Every step maps to something logged: `correlation_id`, `request_id`, `model`, `stop_reason`, `usage`, latency, and the tool sequence. Without those logs the runbook cannot start — which is why telemetry is an enablement prerequisite, not an afterthought.

---

## 7.4 Measuring developer productivity

Measure outcomes, not vanity metrics. Lines of code or raw acceptance counts mislead.

| Metric | What it measures | Why it matters |
| --- | --- | --- |
| **Cycle time / time-to-merge** | Idea → merged change | Core delivery speed; the headline outcome |
| **Review latency** | Time a PR waits for review | AI review passes can cut this materially |
| **Defect escape rate** | Bugs reaching production per change | Guards against speed-at-the-cost-of-quality |
| **Change failure rate / rework** | Share of changes needing fixes | Detects AI output that looks right but is not |
| **Cost per PR** | Token/API spend per merged change | Ties productivity to spend; feeds ROI |

| Meaningful signal | Vanity metric to avoid |
| --- | --- |
| Cycle time / time-to-merge | Lines of code generated |
| Change failure rate / rework | Number of AI suggestions accepted |
| Review throughput and quality | Prompts sent |
| Developer-reported friction removed | Tokens consumed (in isolation) |

:::tip[Exam signal]
An option that measures productivity by **lines of code** or **suggestions accepted** is the trap; the correct answer ties productivity to **delivery outcomes** (cycle time, review latency, defect escape, change-failure rate, cost per PR) — the same per-segment, outcome-focused mindset as D4.
:::

---

## 7.5 Enablement programmes and safe-adoption guardrails

Rolling AI tooling out to developers is a change-management exercise (D6) plus a safety exercise (D5). Do it in phases and let outcome metrics gate each expansion.

### Rollout programme: pilot → champions → scale

| Phase | Who | Goals | Exit criteria |
| --- | --- | --- | --- |
| **Pilot** | 1–2 volunteer teams | Prove value; author baseline `CLAUDE.md`, Skills, commands, MCP catalogue; establish telemetry | Positive cycle-time/review-latency signal; no unsafe incidents |
| **Champions** | Embedded advocates per team | Spread good practice; run office hours; refine shared catalogue; train on limits and review | Champions self-sufficient; standards stable; feedback loop working |
| **Scale** | Org-wide | Enforce managed guardrails; onboard remaining teams; monitor outcome + cost dashboards | Adoption targets met; guardrails non-overridable; metrics trending right |

| Element | Purpose |
| --- | --- |
| Onboarding / training | Teach capabilities and **limits**; how to review AI output |
| Checked-in standards | `CLAUDE.md`, commands, Skills, MCP catalogue as the shared baseline |
| Managed guardrails | Policy-enforced permissions/deny lists; no override of critical rules |
| Champions / office hours | Spread good practice; capture feedback |
| Phased rollout + metrics | Build trust; measure outcome improvements before expanding |
| Review discipline | AI output is reviewed like any contribution (human-in-the-loop) |

---

## 7.6 Hooks and deterministic enforcement for teams

Hooks are the deterministic layer that turns team policy into non-bypassable behaviour. They fire on lifecycle events and, on `PreToolUse`, an **exit code 2 blocks** the action.

| Hook event | Fires when | Team use |
| --- | --- | --- |
| `PreToolUse` | Before a tool runs | Deny destructive commands, enforce policy (exit 2 blocks) |
| `PostToolUse` | After a tool runs | Lint/format, log, run tests on edits |
| `UserPromptSubmit` | On each user prompt | Inject context, scan for secrets/PII |
| `SessionStart` | Session begins | Load project context, print standards |
| `Stop` / `SubagentStop` | Turn/subagent ends | Verify completion, gate on checks |
| `PreCompact` | Before compaction | Snapshot state |
| `Notification` | On notifications | Route to Slack/pager |

```bash
#!/usr/bin/env bash
# PreToolUse hook: block destructive git and force-push regardless of prompt wording
payload=$(cat)
cmd=$(echo "$payload" | jq -r '.tool_input.command // ""')
if echo "$cmd" | grep -Eq 'git push --force|rm -rf|drop table'; then
  echo "Blocked by policy: destructive command '$cmd'" >&2
  exit 2   # exit 2 blocks the tool call
fi
exit 0
```

:::caution[Hook, not prompt]
A team rule like "never force-push" belongs in a **`PreToolUse` hook**, not a CLAUDE.md sentence — the same programmatic-enforcement principle as D5's guardrails. A developer (or the model) can ignore prose; a hook that exits 2 cannot be talked past.
:::

---

## 7.7 An enablement programme charter (artefact)

A rollout is a programme with owners, phases and metrics — not an announcement.

```text
ENABLEMENT PROGRAMME — Claude Code across engineering
Goal: safe, measurable productivity uplift; guardrails non-overridable.
Phase 1 PILOT (weeks 1–4)
  - Scope: 2 volunteer teams
  - Build: ./CLAUDE.md, .claude/settings.json (deny list + hooks), 3 Skills, 3 commands, .mcp.json
  - Telemetry: cycle time, review latency, change-failure rate, cost/PR
  - Exit: positive signal on ≥1 outcome metric; zero unsafe incidents
Phase 2 CHAMPIONS (weeks 5–10)
  - Embed 1 champion/team; office hours; refine shared catalogue
  - Train on limits & how to review AI output
  - Exit: champions self-sufficient; standards stable; feedback loop live
Phase 3 SCALE (weeks 11+)
  - Managed policy enforced org-wide (non-overridable)
  - Onboard remaining teams; outcome + cost dashboards
  - Exit: adoption target met; guardrails non-overridable; metrics trending right
Guardrails throughout: least-privilege tools, secrets in secret manager, human review of AI output.
```

| Programme risk | Control |
| --- | --- |
| Shadow/ungoverned use | Provide the vetted catalogue early; make the paved road the easy road |
| Unsafe output shipped | Review discipline; PostToolUse tests; CI review gate |
| Runaway cost | `/cost`, cost dashboards, per-team budgets/alerts |
| Guardrail bypass | Managed policy (non-overridable), not project files |

---

## 7.8 Scenario walkthrough: standardising Claude Code across 15 teams

**Scenario.** A platform group must roll Claude Code out to 15 teams. Requirements: one coding standard everywhere; a deny-list of destructive commands no developer can override; automated PR review in CI; a shared reviewer subagent and a house-style docs Skill; and a productivity dashboard the director trusts. Today, each developer has ad-hoc personal config and the director wants to measure "lines of code generated".

**Expert reasoning trace.**

<Steps>

1. **Non-overridable rules → managed policy.** The deny-list and required review hook go in **managed/enterprise policy**, deployed via MDM — `CLAUDE.local.md` and project files are overridable and won't satisfy "no one can override".

2. **Shared baseline → checked-in `.claude/`.** `./CLAUDE.md` (standards), `.claude/settings.json` (permissions/hooks/env/model), a `reviewer.md` subagent (read-only, narrow allowlist), a docs **Skill**, and a vetted `.mcp.json` catalogue — all in the repo so every team inherits them.

3. **CI review → headless mode.** `claude -p … --output-format json --allowedTools "Read,Grep" --permission-mode plan`, gating merges on high-severity findings. Least privilege: read-only, structured output.

4. **Fix the metric.** Reject "lines of code" (a vanity metric). Recommend **cycle time, review latency, change-failure/rework rate, defect escape, cost per PR** — delivery outcomes.

5. **Roll out in phases.** Pilot → champions → scale, gated by outcome metrics and guarded by managed policy.

</Steps>

**Why the tempting alternatives are wrong:** per-developer `CLAUDE.local.md` can't enforce org-wide rules; interactive Claude can't run in CI; giving the CI agent all tools breaks least privilege; measuring lines of code rewards volume, not delivered value.

---

## 7.9 Common misconceptions

| Misconception | Reality | Why it matters on the exam |
| --- | --- | --- |
| "`CLAUDE.local.md` can enforce a team rule." | It's personal and git-ignored; use managed policy for non-overridable rules. | Enforcement stems require managed policy. |
| "A CLAUDE.md sentence blocks destructive commands." | Blocking needs a `PreToolUse` hook (exit 2). | Prompt-as-enforcement reappears in D7. |
| "CI can run interactive Claude." | CI needs headless mode with restricted tools and structured output. | CI-integration stems test headless flags. |
| "More tools make a subagent more useful." | Least privilege: narrow the allowlist to what the task needs. | Over-privileged subagent is a wrong answer. |
| "Lines of code / accepted suggestions measure productivity." | Measure delivery outcomes (cycle time, failure rate, cost/PR). | Vanity-metric distractor is common. |
| "Mandating use drives adoption." | Enablement + phased rollout + value reporting drives adoption. | Forced-use answers backfire. |
| "Secrets can live in CLAUDE.md for convenience." | Secrets belong in env/secret managers, never model-visible config. | Exfiltration-risk trap. |

---

## Exam traps in this domain

| Trap | Why it is wrong |
| --- | --- |
| Per-developer ad-hoc config for a team standard | Doesn't scale or govern; use checked-in + managed policy |
| Putting a rule in personal `CLAUDE.local.md` to enforce org-wide | Personal, git-ignored; use managed policy |
| Giving subagents broad tool access | Violates least privilege; keep allowlists narrow |
| Secrets in CLAUDE.md or settings | Exfiltration risk; use env/secret managers |
| Interactive Claude in CI | CI needs **headless** mode with restricted tools |
| Measuring productivity by lines of code / accepted suggestions | Vanity metrics; measure delivery outcomes |
| Rolling out with no training on limits/review | Unsafe adoption; AI output must be reviewed |
| Skipping cost dashboards / `/cost` | No spend visibility; runaway cost |
| Ignoring plan mode before large changes | Skips read-only exploration; riskier edits |
| No override protection on critical policies | Developers can disable guardrails |
| Enforcing a destructive-command block with a CLAUDE.md sentence | Blocking needs a `PreToolUse` hook (exit 2), not prose |
| Rolling out as an announcement rather than a phased programme | No pilot/champions/scale; adoption and safety suffer |
| Assuming exit code 0 from a `PreToolUse` hook blocks a tool | Exit **2** blocks; 0 allows |
| Onboarding teams without the vetted `.claude/` catalogue | Encourages shadow/ungoverned config |
| No per-team cost budgets or alerts | Cost can run away unnoticed across teams |

---

## Practice questions

<Accordions>
  <AccordionItem title="Q1 · A platform team wants a coding standard and a set of denied destructive commands enforced across all repos, with no developer able to override them. What is the BEST mechanism? (Select one)">
    A. Ask each developer to add rules to their `CLAUDE.local.md`.
    B. Managed/enterprise policy plus checked-in `./CLAUDE.md` and `.claude/settings.json` with `permissions.deny`, since managed policy cannot be overridden.
    C. A shared Slack message with the rules.
    D. Email the standards quarterly.

    **Answer: B.** Org-wide, non-overridable enforcement is exactly what managed policy provides, with checked-in project config as the shared baseline. Personal `CLAUDE.local.md` (A) is git-ignored and overridable; Slack (C) and email (D) are not enforcement.
  </AccordionItem>

  <AccordionItem title="Q2 · A team wants Claude to review diffs automatically in CI. What is the correct setup? (Select one)">
    A. Run interactive Claude and have a human paste the diff.
    B. Use headless mode: `claude -p '…' --output-format json` with a restricted `--allowedTools` and an appropriate `--permission-mode`, so CI can parse findings and gate the build.
    C. Give the CI agent all tools for flexibility.
    D. Disable permissions in CI to avoid friction.

    **Answer: B.** CI is non-interactive, so headless mode with structured output and restricted tools is correct. Interactive use (A) can't run in CI; all-tools (C) and disabled permissions (D) violate least privilege.
  </AccordionItem>

  <AccordionItem title="Q3 · How should a shared, progressively-loaded capability (e.g. a house style for API docs) be distributed to the team? (Select one)">
    A. Paste it into every prompt.
    B. As a checked-in Skill (`.claude/skills/<name>/SKILL.md`) loaded on demand.
    C. In each developer's `CLAUDE.local.md`.
    D. In a personal settings file.

    **Answer: B.** Skills package reusable capability and load progressively; checking them in shares them across the team. Pasting per prompt (A) bloats context; personal files (C, D) don't share or govern.
  </AccordionItem>

  <AccordionItem title="Q4 · A manager proposes measuring AI productivity by counting lines of code Claude generates and suggestions accepted. What is the architect's guidance? (Select one)">
    A. Those are good primary metrics.
    B. Measure delivery outcomes — cycle time, change-failure/rework rate, review quality — because lines of code and accepted-suggestion counts are vanity metrics that don't reflect value.
    C. Measure tokens consumed instead.
    D. Don't measure productivity at all.

    **Answer: B.** Productivity should tie to delivery outcomes, not volume metrics. Lines/acceptances (A) and tokens (C) are vanity signals; not measuring (D) forfeits the ability to demonstrate value.
  </AccordionItem>

  <AccordionItem title="Q5 · A subagent for codebase exploration is configured with write and shell tools 'just in case'. What is the correct configuration? (Select two)">
    A. Restrict the subagent's tools allowlist to read-only exploration tools it actually needs.
    B. Keep the broad tool set for flexibility.
    C. Use plan/read-only mode for exploration and grant write access only where a task requires it.
    D. Put credentials in the subagent's CLAUDE.md so it can act freely.
    E. Give it all MCP servers in the catalogue.

    **Answer: A and C.** Least privilege: narrow the allowlist to what the exploration task needs and use read-only/plan mode, granting more only when required. A broad tool set (B) and all MCP servers (E) are excessive agency; credentials in CLAUDE.md (D) is an exfiltration risk.
  </AccordionItem>

  <AccordionItem title="Q6 · What should a safe developer-adoption programme include? (Select two)">
    A. Training that covers Claude's limits and how to review AI output.
    B. Checked-in standards (CLAUDE.md, commands, Skills, MCP catalogue) plus managed guardrails and a phased rollout with outcome metrics.
    C. Immediate org-wide mandatory use with no support.
    D. Removing human review of AI-generated code to move faster.
    E. Letting each developer add unvetted MCP servers.

    **Answer: A and B.** Safe adoption pairs enablement (training on limits/review) with governed, checked-in standards, guardrails and phased rollout. Forced use without support (C), removing review (D), and unvetted MCP servers (E) are unsafe.
  </AccordionItem>

  <AccordionItem title="Q7 · Which asset best gives operators visibility and control over Claude spend across teams? (Select one)">
    A. Lines-of-code reports.
    B. Cost dashboards fed by per-request token/cost telemetry, plus `/cost` in Claude Code sessions.
    C. A quarterly invoice only.
    D. Disabling logging to save money.

    **Answer: B.** Per-request token/cost telemetry surfaced in dashboards (and `/cost`) gives real spend visibility and control. LOC reports (A) are unrelated; a quarterly invoice (C) is too coarse; disabling logging (D) removes the very data needed.
  </AccordionItem>

  <AccordionItem title="Q8 · Before a large automated migration across a codebase, what is the safest first step in Claude Code? (Select one)">
    A. Apply all changes immediately and review afterward.
    B. Use plan mode (read-only) to explore and produce a plan, then apply changes with appropriate permissions and tests.
    C. Give the agent unrestricted write and shell access.
    D. Skip tests to finish faster.

    **Answer: B.** Plan mode explores read-only and produces a reviewable plan before edits, reducing risk on large changes. Applying blindly (A), unrestricted access (C), and skipping tests (D) all increase blast radius.
  </AccordionItem>

  <AccordionItem title="Q9 · An enterprise wants a deny-list of destructive commands and a required review hook applied to every developer and repo, immune to local overrides. Where should this live? (Select one)">
    A. Each team's project `.claude/settings.json`.
    B. Managed policy settings (admin-controlled path), because it cannot be overridden by user, project, or local files.
    C. Every developer's `settings.local.json`.
    D. A wiki page of guidelines.

    **Answer: B.** Only managed policy is non-overridable and applies org-wide, which is exactly the requirement. Project settings (A) can be overridden per repo and are not guaranteed everywhere; `settings.local.json` (C) is personal and git-ignored; a wiki (D) is not enforcement.
  </AccordionItem>

  <AccordionItem title="Q10 · A platform team wants a phased, low-risk rollout of Claude Code across the org. Which sequence best reflects safe adoption? (Select one)">
    A. Mandate org-wide use on day one to maximise ROI.
    B. Pilot with 1–2 teams and establish telemetry, then champions to spread practice and refine shared standards, then scale org-wide with managed guardrails and outcome/cost dashboards.
    C. Let each developer adopt whatever they like with no standards.
    D. Roll out to everyone but disable review to move faster.

    **Answer: B.** Pilot → champions → scale, gated by outcome metrics and guardrails, is the safe change-management pattern. A day-one mandate (A) and ungoverned free-for-all (C) skip the trust-building and standardisation; disabling review (D) removes the human-in-the-loop safeguard.
  </AccordionItem>

  <AccordionItem title="Q11 · A Claude-backed feature is misbehaving in production. Which TWO steps belong at the start of the runbook/trace-analysis flow? (Select two)">
    A. Capture the correlation ID and gather request IDs for the affected session.
    B. Immediately rewrite the system prompt and redeploy.
    C. Classify the failure as integration vs model-output using the HTTP status and `stop_reason`.
    D. Restart all services and hope it clears.
    E. Delete the logs to reduce noise.

    **Answer: A and C.** Diagnosis begins by capturing identifiers and classifying the layer from concrete signals (status code, `stop_reason`) so the right fix is applied. Blind prompt rewrites (B) and restarts (D) skip diagnosis; deleting logs (E) destroys the evidence the runbook depends on.
  </AccordionItem>

  <AccordionItem title="Q12 · A director asks for a productivity dashboard for AI-assisted development. Which set of metrics should the architect recommend? (Select one)">
    A. Lines of code generated and number of suggestions accepted.
    B. Cycle time / time-to-merge, review latency, defect escape rate, change-failure/rework rate, and cost per PR.
    C. Prompts sent per developer per day.
    D. Tokens consumed per developer.

    **Answer: B.** These tie productivity to delivery outcomes and cost, resisting gaming and reflecting real value. Lines of code and accepted suggestions (A), prompt counts (C), and raw token consumption (D) are vanity metrics that do not measure delivered value or quality.
  </AccordionItem>

  <AccordionItem title="Q13 · A platform team must guarantee that `git push --force` is blocked for every developer, unbypassable. Where does this belong? (Select one)">
    A. A sentence in `./CLAUDE.md`.
    B. A `PreToolUse` hook (exit code 2 blocks the call) delivered via managed policy so it cannot be overridden.
    C. A note in each developer's `CLAUDE.local.md`.
    D. A Slack reminder.

    **Answer: B.** Deterministic, non-bypassable blocking is a `PreToolUse` hook (exit 2) enforced through managed policy. A CLAUDE.md sentence (A) is prose guidance; `CLAUDE.local.md` (C) is personal/overridable; Slack (D) is not enforcement.
  </AccordionItem>

  <AccordionItem title="Q14 · What exit code must a `PreToolUse` hook return to BLOCK the tool call? (Select one)">
    A. Exit 0.
    B. Exit 2.
    C. Exit 1 only.
    D. Any non-zero code prints a warning but never blocks.

    **Answer: B.** A `PreToolUse` hook blocks the tool when it exits with code 2. Exit 0 (A) allows; the blocking semantics are specifically exit 2, not merely any non-zero (C, D).
  </AccordionItem>

  <AccordionItem title="Q15 · A platform group is rolling Claude Code to 15 teams and wants low risk. Which sequence and controls are BEST? (Select two)">
    A. Pilot with 2 teams and telemetry, then champions to spread practice, then scale org-wide.
    B. Enforce the deny-list and required review hook via managed policy (non-overridable) plus a checked-in `.claude/` catalogue.
    C. Mandate org-wide use on day one to maximise ROI.
    D. Let each team choose its own unvetted MCP servers.
    E. Measure success by lines of code generated.

    **Answer: A and B.** Phased rollout plus managed-policy enforcement and a shared checked-in catalogue is the safe pattern. A day-one mandate (C) skips trust-building; unvetted MCP servers (D) break governance; lines of code (E) is a vanity metric.
  </AccordionItem>

  <AccordionItem title="Q16 · A reviewer subagent for read-only code review is configured with write and Bash tools. What is the correct configuration? (Select one)">
    A. Keep the broad tool set for flexibility.
    B. Restrict the subagent's tools allowlist to read-only tools (e.g. Read, Grep) it actually needs for review.
    C. Give it all MCP servers too.
    D. Put credentials in its agent file.

    **Answer: B.** Least privilege narrows the subagent to the read-only tools its task needs. A broad set (A) and all MCP servers (C) are excessive agency; credentials in the agent file (D) are an exfiltration risk.
  </AccordionItem>

  <AccordionItem title="Q17 · During the enablement pilot, which exit criterion should gate expansion to the champions phase? (Select one)">
    A. A fixed calendar date regardless of results.
    B. A positive signal on at least one delivery-outcome metric (e.g. cycle time or review latency) with no unsafe incidents.
    C. The number of prompts developers sent.
    D. Lines of code generated by Claude.

    **Answer: B.** Phase gates are outcome-based: demonstrate a delivery-outcome improvement safely before expanding. A calendar date (A) ignores results; prompt counts (C) and lines of code (D) are vanity metrics.
  </AccordionItem>

  <AccordionItem title="Q18 · A PostToolUse hook is proposed to run tests and formatters after Claude edits files. Is this appropriate, and why? (Select one)">
    A. No; hooks can only block, never run follow-up work.
    B. Yes; `PostToolUse` fires after a tool runs, making it the right place to lint/format and run tests on edits.
    C. No; testing must be manual.
    D. Yes, but only in `UserPromptSubmit`.

    **Answer: B.** `PostToolUse` runs after a tool completes, which is exactly where post-edit linting/formatting/tests belong. Hooks do more than block (A); automated testing is appropriate (C); `UserPromptSubmit` (D) fires on prompts, not after edits.
  </AccordionItem>
</Accordions>

## Key takeaways

- Configure for **teams**: managed policy (non-overridable) + checked-in `./CLAUDE.md` and `.claude/settings.json`, not per-developer ad-hoc files.
- Share **Skills, slash commands, subagents and a vetted MCP catalogue**; keep subagent **tools allowlists narrow** and secrets in env/secret managers.
- Wire AI into workflows via **headless mode** in CI with structured output and restricted tools; use **plan mode** before large changes.
- Support operations with **runbooks, trace analysis and cost dashboards** (`/cost`).
- Measure productivity by **delivery outcomes** (cycle time, failure rate, quality), never lines of code or accepted-suggestion counts.
- Run **safe-adoption enablement**: training on limits and review, checked-in standards, managed guardrails, and phased rollout with outcome metrics.
- Enforce team rules with **hooks** (`PreToolUse` exit 2 blocks; `PostToolUse` lints/tests) delivered via **managed policy**, not CLAUDE.md prose.
- Run rollout as a **programme** (pilot → champions → scale) with outcome-based **exit criteria**, not an announcement.
- Keep subagents **least-privilege** (narrow tools allowlist), secrets in secret managers, and gate expansion on delivery-outcome signals, never vanity metrics.