Lesson 7 · Domain 3 — Claude Code Configuration & Workflows (20% of exam)

Plan Mode, Iterative Refinement & CI/CD

Three task statements, one closing lesson for Domain 3: when to plan before acting, how to steer Claude Code toward a working result faster, and how to run it unattended in a pipeline.

Plan mode vs. direct execution

The official guide's own sample question sets the bar clearly: restructuring a monolith into microservices — dozens of files touched, multiple valid service boundaries, real architectural tradeoffs to weigh. The correct move is plan mode: explore the codebase, understand dependencies, and design an approach before any code changes. Starting direct execution and "letting structure emerge incrementally" risks exactly the costly rework plan mode exists to prevent.

Direct execution is for the opposite shape of task: a single-file bug fix with a clear stack trace, a validation check added to one function — well-scoped, well-understood, low ambiguity.

For verbose discovery phases inside a plan — reading dozens of files to build understanding — delegate to the Explore subagent. It does the wide reading and returns a summary, keeping the noisy exploration out of your main context window.

Iterative refinement, three techniques

One more judgment call: when several issues genuinely interact (a fix to one touches the same code as another), put them in a single detailed message. When they're independent, fix them sequentially instead — bundling unrelated changes just adds noise to each iteration.

Claude Code in CI/CD

# -p (--print) runs Claude Code non-interactively — required for any
# automated pipeline, since interactive prompts would just hang.
claude -p "Review this PR diff for bugs and security issues" \
  --output-format json \
  --json-schema ./review-schema.json \
  < pr-diff.patch > review-findings.json

--output-format json combined with --json-schema produces machine-parseable findings you can post as inline PR comments programmatically — free text won't do that reliably. CLAUDE.md still does its usual job here too: it's how you hand CI-invoked Claude Code your testing standards, fixture conventions, and review criteria without re-stating them in every invocation.

Why review with a fresh instance, not the generating session
A session that just generated code carries its own reasoning forward — it's biased toward believing its own decisions were sound, and less likely to question them in the same breath. An independent review instance, with no memory of that reasoning, catches more. This is the CI-specific edge of a pattern you'll see again, more formally, in Domain 4's multi-instance review.

Why this matters beyond the exam

Primary source: Anthropic's Extend Claude Code docs and the Steering Claude Code blog post cover plan mode, non-interactive flags, and iteration technique directly — this lesson compresses Task Statements 3.4, 3.5, and 3.6.

Check your understanding

Q1. You're restructuring a monolith into microservices — dozens of files, multiple valid service boundaries, real architectural tradeoffs. What's the right approach?
Q2. Which CLI flag combination gets you machine-parseable findings suitable for posting automated PR comments?
Q3. Why is an independent Claude Code instance generally more reliable reviewing code than the same session that just generated it?

Want to work through when you'd choose plan mode for something in your own codebase? Describe the task and I'll help you reason through it.