Plan Mode and Claude Code in CI/CD

Arc 3 closes with two operational judgments: when to make Claude plan before it acts (Task 3.4) and how to run Claude Code inside a pipeline (Task 3.6). Both are the Code Generation and CI/CD scenarios’ bread and butter. Plan mode and the CLI flags are confirmable against the live tool and the exam’s own documentation; where CI quality depends on the model, it’s flagged ⚠️.

Plan mode vs. direct execution

Plan mode is a Claude Code mode — reachable as /plan, or in the SDK as permission_mode="plan" (verified in claude-agent-sdk 0.2.128) — in which Claude can read, explore, and design but not edit. It investigates the codebase and proposes an approach, and only after you approve the plan does it make changes. Direct execution is the opposite: Claude changes files immediately.

The exam tests when to use which, and the line is complexity and reversibility:

• Plan mode for tasks with real stakes: large-scale changes, multiple valid approaches, architectural decisions, multi-file modifications. A library migration touching 45 files, a microservice restructuring, choosing between two integration approaches with different infrastructure — these want a plan first, because committing to the wrong approach is expensive rework. Plan mode lets Claude explore the design space safely, before a single edit.
• Direct execution for simple, well-scoped changes: a single-file bug fix with a clear stack trace, adding one validation check to one function. Planning these is ceremony; the scope is obvious and the change is small.

The strong pattern the blueprint highlights is combining them: plan mode for the investigation, direct execution for the implementation. Plan the library migration — let Claude map the dependencies and propose the sequence — then execute the approved plan directly. Investigation is where planning pays; implementation of an agreed plan doesn’t need it.

One supporting tool: the Explore subagent. Discovery phases are verbose — grepping, reading, tracing — and that output can exhaust the main conversation’s context. Delegating discovery to the Explore subagent isolates the verbose work and returns a summary to the main agent, preserving context for the actual task. It’s the context-isolation move again, and it’s what keeps a multi-phase planning task from filling the window with grep output before it reaches the design.

Claude Code in CI/CD

Task 3.6 is running Claude Code non-interactively in an automated pipeline — the CI/CD scenario’s automated reviews and test generation. The mechanics, per the exam’s own documentation:

• -p (or --print) runs Claude Code in non-interactive mode — it takes the prompt, produces output, and exits, rather than waiting for input. This is the flag that prevents a CI job from hanging on an interactive prompt that will never be answered.
• --output-format json with --json-schema produces machine-parseable structured output — findings the pipeline can post as inline PR comments without brittle text-scraping. (This is the structured-output-via-schema idea, at the CLI level.)
• CLAUDE.md carries the project context into a CI-invoked run — testing standards, fixture conventions, review criteria. The CI instance has no interactive history, so what it knows about the project is CLAUDE.md; documenting standards there is what makes CI reviews and test generation good rather than generic.

claude -p "Review the changes in this PR for correctness bugs." \
  --output-format json --json-schema ./review-schema.json

Two operational patterns the exam draws on, both about not repeating work:

• Re-running reviews on new commits — include the prior review findings in context and instruct Claude to report only new or still-unaddressed issues, so the pipeline doesn’t post the same comment on every push.
• Test generation — provide the existing test files in context so Claude doesn’t suggest scenarios already covered, and document what makes a test valuable in CLAUDE.md so it generates high-signal tests rather than low-value padding. (⚠️ the resulting review/test quality is model-dependent, pending the key pass; the flags and context patterns are the exam content.)

The independent-reviewer principle

The most conceptually important point in 3.6, and one that reaches into Domain 4’s multi-pass review: the same Claude session that generated code is less effective at reviewing its own changes than an independent instance. A session that wrote the code carries its own reasoning — the assumptions it made, the design it chose — and that context makes it less likely to question its own decisions. A fresh instance, with no stake in the original reasoning, catches subtle issues the author-session rationalizes past.

So in a CI pipeline, the review should run in an independent instance — not a continuation of the generation session, and not the same session asked to “now review your work.” This is why session-context isolation matters here: the value of the review comes precisely from not sharing context with the generator. When an exam item pits “have the generating session review itself” against “spin up a separate reviewer,” the separate reviewer is the right answer.

Final thoughts

Plan mode buys safe exploration before costly, multi-file, or architectural changes; direct execution is for small, clear-scoped edits; and the strong pattern is planning the investigation, then executing the approved plan directly, with the Explore subagent keeping discovery from eating your context. In CI/CD, -p prevents interactive hangs, --output-format json with --json-schema yields parseable findings, and CLAUDE.md supplies the project context a headless run otherwise lacks. The principle threading it all: reviews belong to an independent instance, because a session invested in its own reasoning is the worst judge of it. That completes Domain 3.

Next: Arc 4 opens with precision prompting and few-shot examples — writing prompts that reduce false positives and produce consistent output.