Plan Mode and Claude Code in CI/CD

The last two chapters gave Claude Code its standing instructions: CLAUDE.md and rules, then commands and skills. This chapter is about two decisions that sit on top of that configuration. The first is whether to let Claude think before it touches anything. The second is how to run it in a place where nobody is at the keyboard to approve its next move. The first is plan mode; the second is CI/CD. They belong together: the moment you take the human out of the loop, you have to be far more deliberate about what the agent may do and how you check its work.

What plan mode is

Give Claude a task and its instinct is to act — read a file, make an edit, run a command. Usually that is exactly what you want. But for some tasks the first edit is already a commitment. You have picked an approach, and if it turns out to be wrong you will be unwinding it across dozens of files. Plan mode exists for those.

Plan mode is a Claude Code mode in which Claude can read, explore, and design but not edit. You reach it as /plan, or in the SDK as permission_mode="plan". It investigates the codebase, proposes an approach, and then waits. Only after you approve the plan does it begin changing files. Direct execution is the opposite and the default: Claude changes files immediately.

The real distinction is that plan mode separates deciding what to do from doing it. Direct execution fuses the two. That fusion is a feature when the decision is trivial and a liability when it isn’t. That is the whole basis for choosing between them.

When to plan, and when it is just ceremony

Planning has a price. It costs a round-trip of exploration, plus a plan you have to read and approve before anything happens. On a small change, that price buys you nothing. So the question is when the plan pays for itself, 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. 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 is combining them: plan mode for the investigation, direct execution for the implementation. Plan the library migration, letting Claude map the dependencies and propose the sequence, then execute the approved plan directly. Investigation is where planning pays; implementation of an agreed plan does not need it.

Keeping discovery from eating the context

Planning tends to be expensive on context. The discovery phase is verbose — grepping, reading, tracing — and that output can exhaust the main conversation’s context before Claude even reaches the design. The Explore subagent is the fix. Delegating discovery to it isolates the verbose work and returns a summary to the main agent, preserving context for the actual task. It is the context-isolation move again. It keeps a multi-phase planning task from filling the window with grep output before it reaches the design.

Running Claude Code where no human is watching

Everything so far assumes you are present to approve a plan or answer a prompt. CI/CD removes that assumption. A pipeline runs Claude Code on every push with nobody at the terminal, and that changes two things. First, the agent cannot stop to ask: anything that waits for input becomes a job that hangs forever. Second, whatever the run needs to know about your project has to be written down in advance, because there is no interactive history to lean on. Non-interactive execution is the skill here, and it powers the CI/CD scenario’s automated reviews and test generation.

The mechanics:

• -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, 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; the CLI flags, hooks, and structured-output machinery this workflow relies on hold.)

The independent-reviewer principle

One more idea reaches forward 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. 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. 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.