Plan Mode vs Direct Execution

The Plan Mode vs Direct Execution decision sits at the heart of Domain 3 (Claude Code Configuration and Workflows) of the CCA-F exam. Task statement 3.4 asks candidates to determine when Plan Mode vs Direct Execution is the correct architectural choice, and community pass reports consistently flag this as one of the highest-frequency trap areas on the entire exam. The question is never "which mode is better" — both are first-class Claude Code workflows. The question is always "which mode correctly matches the blast radius, ambiguity, and reversibility of the task described in the scenario."

This study note walks through the full surface of Plan Mode vs Direct Execution a CCA-F candidate is expected to master: the precise definition of each mode, the concrete signals that justify mandating plan mode, the equally concrete signals that direct execution is the right default, the plan format Claude Code produces, user approval semantics, CLAUDE.md configuration for default behavior, hybrid patterns, the cost of always-on planning, the Explore subagent pattern for isolating noisy discovery output, and the exam traps that punish candidates who default to "plan mode is always safer." A dedicated section ties every concept back to the Code Generation and Developer Productivity exam scenarios where Plan Mode vs Direct Execution questions cluster most densely.

Plan Mode Definition — Claude Produces Execution Plan Before Taking Actions

Plan Mode is a Claude Code workflow in which Claude first produces a structured, reviewable execution plan — a numbered list of the actions it intends to take, the files it intends to touch, and the tool sequence it intends to use — before any filesystem mutation occurs. The plan is presented to the user for review. Nothing outside the plan is executed until the user approves, amends, or rejects it.

Plan Mode is explicitly designed for tasks where the cost of acting incorrectly exceeds the cost of a short delay for review. In plan mode Claude behaves like a senior engineer who writes a one-page change brief before touching production code. The mode does not make Claude smarter — the underlying model is the same — but it does change when Claude commits to actions. That temporal separation is the entire point.

Plan Mode Is About Commitment Timing, Not Capability

A common misunderstanding — aggressively exploited by CCA-F distractor answers — treats Plan Mode as a more powerful or smarter variant of Claude. It is not. Plan Mode uses the same model, the same tools, and the same context Claude already had. What changes is the commitment point: in plan mode Claude must verbalize its full intent before acting; in direct execution Claude interleaves reasoning and action. Plan Mode trades a small amount of latency for a large amount of reviewability on high-blast-radius work.

Direct Execution Definition — Claude Acts Immediately Without Explicit Planning Step

Direct Execution is the default Claude Code workflow in which Claude reasons about the task and immediately begins executing tool calls — reading files, editing code, running commands — interleaving short reasoning bursts with concrete actions. There is no pre-approved plan; there is only an ongoing agentic loop whose work can be observed as it happens.

Direct Execution is not reckless; it is simply unblocked. The model is still capable of planning internally, rolling back after a failed Edit, or escalating to the user when it hits ambiguity. What Direct Execution removes is the mandatory pre-approval gate. For tasks where the mutation is small, reversible, and well-scoped, this is the correct choice — the overhead of producing a formal plan and waiting for approval exceeds the value the plan would provide.

Direct Execution Is the Default for a Reason

Claude Code defaults to Direct Execution because the median development task — a typo, a one-line fix, a clear test update — benefits from immediate action and is penalized by ceremonial planning. Forcing every task through plan mode would turn a ten-second edit into a two-minute approval dance. The CCA-F exam rewards candidates who recognize that Plan Mode vs Direct Execution is a matching problem, not a preference.

Plan Mode Triggers — Task Complexity Signals, Risk Signals, Explicit User Request

Four categories of signal justify routing a task into Plan Mode.

Task Complexity Signals

Complexity signals appear directly in the request. "Restructure the monolith into microservices," "migrate all API routes from v1 to v2," "refactor the authentication layer to support SSO," "extract the shared logging utility into a new package and update every caller" — each implies changes spanning many files, several architectural decisions, and multiple valid approaches. These are plan-mode tasks because the approach itself is a decision worth reviewing, not just the final patch.

Risk Signals

Risk signals highlight blast radius. Touching build configuration, migration scripts, deployment manifests, payment-processing code, or security-critical modules means a mistake has outsized consequences. Any time a task changes how the system starts, deploys, authenticates, or bills, plan mode is warranted — not because Claude is untrustworthy, but because the review step is cheap insurance.

Ambiguity Signals

Ambiguity signals appear when multiple valid interpretations of the request exist. "Clean up the user module" could mean deleting dead code, reformatting, splitting files, or all three. When the request does not uniquely determine the intended change, plan mode forces the ambiguity into the open where the user resolves it before any code moves.

Explicit User Request

Users can explicitly ask Claude to plan before acting. Phrases like "plan this out before changing anything," "walk me through the approach first," or "what files would you touch?" are direct invocations of plan mode. The CCA-F exam frequently tests whether candidates recognize that an explicit user request overrides any default mode configured in CLAUDE.md.

When to Mandate Plan Mode — High-Blast-Radius Tasks, Unfamiliar Codebases, Multi-File Refactors

Plan Mode should be mandated — not optional — for three canonical task categories that the exam treats as settled law.

High-Blast-Radius Tasks

A task has high blast radius when an incorrect action cannot be quickly reverted. Database schema migrations, production configuration changes, wholesale dependency upgrades, and refactors that touch public API contracts all sit in this category. The cost of reverting a bad plan is five minutes; the cost of reverting a bad half-completed refactor is an afternoon.

Unfamiliar Codebases

When Claude is working in a codebase it has not extensively explored, plan mode is the correct first step. The plan itself becomes the exploration artifact: Claude proposes which files it believes are relevant, the user corrects the map, and only then does execution begin. This converts exploration from a silent, context-consuming activity into a reviewable document.

Multi-File Refactors

Any task that crosses file boundaries — especially when the number of affected files is ambiguous — belongs in plan mode. The canonical example the exam uses is a monolith-to-microservices restructure affecting 45+ files. Direct execution on such a task would burn context on discovery output long before any code moves; plan mode front-loads the structural decisions and keeps the subsequent execution phase focused.

When Direct Execution Is Appropriate — Well-Scoped, Reversible, Single-File Tasks

Direct Execution is equally a first-class answer when the scenario telegraphs small scope.

Well-Scoped Tasks

Well-scoped means the intended change is unambiguously specified. "Add a null check on line 42 of auth.ts before the token.verify() call" is well-scoped; there is nothing to plan. The request itself is the plan.

Reversible Tasks

A task is reversible when an incorrect change is trivially undone — a single-file edit with version control, a local configuration tweak, a test update. Direct Execution suits reversible tasks because the cost of acting on a slightly-wrong interpretation is a cheap git checkout.

Single-File Tasks

Single-file tasks rarely justify planning overhead. "Fix this bug in validator.py," "rename this function," "add this import" — the planning document would be longer than the patch. Forcing plan mode here adds latency without adding reviewability.

The Sample Q5 Pattern — Adding a Date Validation Conditional

The CCA-F exam guide's sample Q5 uses exactly this shape as a distractor: a scenario describes adding a single date-range validation conditional to an existing function, and one answer choice suggests switching into plan mode. That answer is wrong. The task is a single-file, reversible, well-scoped change — the prototypical direct execution case. Candidates who default to "plan mode is always safer" fail this question.

Plan Format — Numbered Steps, Tool Sequence, File Impact List

Claude Code's plan mode produces a predictable plan shape the exam expects candidates to recognize.

Numbered Steps

Every plan is a numbered list of discrete steps. Numbering makes the plan reviewable step-by-step and makes partial approval possible — a user can say "approve steps 1–3, let me think about step 4." Free-form prose is not a plan; a bulleted numbered list is.

Tool Sequence

Each step specifies the intended tool: Read src/auth.ts, Grep -r "verifyToken", Edit src/auth.ts, Bash npm test. Declaring the tool sequence up front lets the user spot dangerous operations (Bash, Write on existing files) before they run.

File Impact List

Every plan includes the explicit list of files the plan will create, modify, or delete. The file impact list is the single most valuable element for reviewing large refactors; it surfaces the full blast radius at a glance and catches accidental inclusions.

Risk and Assumption Notes

Well-formed plans also enumerate assumptions Claude made about the environment ("assuming the test suite runs via npm test") and risks it foresees ("the migration will require a brief downtime window"). These notes are the artifact the user reviews most carefully.

Plan Validation — User Review and Approval Before Execution Proceeds

The plan itself is inert until the user acts on it. Three outcomes are possible.

Approve As-Is

The user approves the plan verbatim. Claude Code transitions out of plan mode and executes the steps in order. Approval is not silent consent — the user explicitly confirms.

Approve With Amendments

The user approves the plan but requests specific changes. "Approved, but skip step 4 and add a rollback script to step 6." Claude Code revises the plan to reflect the amendments and presents the revision for re-approval before executing.

Reject

The user rejects the plan entirely, usually because the chosen approach was wrong. Rejection does not terminate the conversation — it sends Claude back to planning with the user's feedback. Iterative planning is normal; a first plan is rarely the final plan on complex work.

Forcing Plan Mode in CLAUDE.md — Default Behavior Configuration

Plan Mode can be set as the default for a project by adding an instruction to the project-level CLAUDE.md. A directive like "Always produce a plan before making any filesystem-mutating change in this repository" forces plan mode regardless of task size. This is appropriate for codebases where the median change is high-risk (infrastructure-as-code, payment services, regulated systems) but inappropriate for most application repositories because it imposes ceremony on every task.

Directory-Level Overrides

Because CLAUDE.md supports a hierarchy, project-wide plan-mode defaults can be selectively relaxed for directories where tasks are consistently low-risk (for example, a /docs directory where changes are cosmetic). Directory-level CLAUDE.md supplements the project default.

Plan Mode and Non-Interactive CI

Plan Mode is fundamentally interactive — it requires a user to approve, amend, or reject the plan. In non-interactive CI pipelines using the -p flag, enforced plan mode breaks automation because there is no user present to approve. Pipelines that must run Claude Code non-interactively should either avoid plan mode entirely or supply approval programmatically. The CCA-F exam tests this interaction.

Hybrid Patterns — Auto-Plan for Certain File Patterns, Direct for Others

Mature Claude Code setups combine both modes by routing on signal. Three hybrid patterns recur in exam scenarios.

Path-Based Routing

Plan mode is mandated for paths matching infrastructure patterns (infra/**, migrations/**, .github/workflows/**) while the rest of the repository defaults to Direct Execution. The .claude/rules/ path-specific rule system (Task 3.3) is the mechanism that enforces this routing.

Operation-Based Routing

Plan mode is mandated when the task involves schema changes, dependency bumps, or public API modifications, while local edits inside a single file default to Direct Execution. The CLAUDE.md instruction encodes the operation types that require planning.

Investigate-Plan-Execute Composition

For the most complex tasks — library migrations, framework upgrades, large restructures — the optimal workflow splits into three phases. First, an Explore subagent performs discovery and returns a summary. Second, Claude Code in plan mode produces a plan using the summary. Third, Claude Code in direct execution mode implements the approved plan step-by-step. This three-phase pattern is explicitly called out in exam scenarios involving library migrations.

Explore Subagent — Isolating Verbose Discovery Output

The Explore subagent is a dedicated investigation pattern that pairs naturally with Plan Mode for large codebases.

Why Isolate Discovery Output

Large-codebase exploration is token-heavy. Reading thirty files to map a module's dependency graph can consume tens of thousands of tokens, most of which is noise — the main conversation needs the conclusion ("here are the 45 call sites that must be updated"), not the raw file contents. Running discovery in a subagent keeps the main coordinator's context focused on decisions.

Context Window Exhaustion

Without the Explore subagent, discovery-heavy tasks frequently exhaust the context window before the actual work begins. Claude Code then loses access to earlier instructions, CLAUDE.md content, or the user's original request. The Explore subagent is the canonical mitigation.

Pairing Explore With Plan Mode

The canonical pattern is: spawn an Explore subagent to map the affected surface, receive its summary, switch into Plan Mode to produce an execution plan from the summary, then execute the approved plan. This is the recommended shape for library migrations and large restructures — a pattern the CCA-F exam tests directly in the Code Generation scenario.

Plan Mode in Agentic Loops — Using Plan Step as First Loop Iteration

Inside the Agent SDK, Plan Mode can be encoded as an explicit first iteration of the agentic loop. The first loop produces the plan; the user approves; subsequent iterations execute the plan steps one by one, with tool_result observations feeding back after each action.

Plan-First Loop Shape

A plan-first loop has a predictable message trace: user request → plan (assistant) → user approval → tool_use (step 1) → tool_result → tool_use (step 2) → tool_result → ... → end_turn. The stop_reason values follow the standard agentic loop semantics; plan mode changes what Claude says in early iterations, not how the loop terminates.

Plan Mode and Subagent Spawning

When the overall work is decomposed across subagents, each subagent can independently decide whether to plan. A coordinator might run in plan mode (producing the overall execution plan) while each subagent runs its leaf task in direct execution mode. This mirrors real engineering: senior engineers plan, line workers execute.

Cost of Planning — Latency and Token Overhead When Plan Mode Is Always On

Plan Mode is not free. Two costs matter for architectural judgment.

Latency Overhead

Plan mode inserts a synchronous pause for user review. On small tasks this pause dominates the total wall-clock time. A ten-second edit becomes a two-minute ceremony: plan generation, user reads the plan, user approves, execution. For well-scoped work this overhead is pure waste.

Token Overhead

Every plan is itself a generated artifact — numbered steps, file lists, risk notes — that consumes output tokens. The plan then occupies context for the remainder of the session. On a long task with many plans, tokens spent on planning meta-work compete with tokens spent on actual code.

When the Cost Is Worth It

Planning cost is worth paying when the alternative cost (a half-completed refactor, a wrong architectural direction, a non-reversible change) is substantially larger. The blast radius of the task is the calibration. For a production schema migration, the planning tax is trivial insurance. For a typo fix, it is ceremony theater.

Plain-Language Explanation: Plan Mode vs Direct Execution

Plan Mode vs Direct Execution becomes intuitive once grounded in physical, everyday parallels. Three analogies cover the full decision space.

Analogy 1: The Kitchen — Mise en Place vs Cooking on the Line

A short-order cook fries an egg directly: crack, salt, plate, serve. No mise en place, no written sequence, no sous chef review. This is Direct Execution. A banquet chef cooking for two hundred guests does not work that way. Before service begins, the banquet chef writes a prep list, assigns each station a timing, and walks the sous chefs through the sequence. Only after the line signs off does anyone touch a pan. That pre-service briefing is Plan Mode.

Both cooks are equally capable. The choice of workflow is dictated by the blast radius of a mistake. A mis-salted egg costs an egg. A mis-timed banquet ruins an event. Claude Code is the same kitchen — one cook, two workflows, chosen by the size of the order.

This analogy also illustrates the Explore subagent: the banquet chef sends a junior cook to inventory the walk-in before the plan is written. The junior cook returns with "we have 15 kilos of salmon and no dill." The head chef then plans the menu with that summary in hand. The junior cook's full walk through the walk-in (every shelf, every container) never enters the head chef's memory — only the summary does. That is exactly how the Explore subagent preserves main-conversation context.

Analogy 2: The Open-Book Exam — Scratch Outline vs First-Pass Answer

On an open-book exam, two strategies exist. For a multiple-choice question you recognize immediately, you circle the answer and move on. That is Direct Execution — the question is well-scoped, the answer is reversible (you can change it later), and the cost of a wrong guess is small.

For a long-form essay on a topic you haven't seen phrased quite this way before, you do not start writing prose. You outline first: thesis, three supporting arguments, conclusion, counterexample. Only after the outline holds together do you expand it into paragraphs. That outline is Plan Mode. Without it, you risk writing four pages that argue the wrong thesis and having no time to rewrite.

The exam rewards the candidate who correctly matches strategy to question type. The CCA-F exam rewards the candidate who correctly matches Plan Mode vs Direct Execution to the task described in the scenario.

Analogy 3: The Construction Site — Work Order vs Punch List

A contractor walking a site with a homeowner encounters both kinds of work. A loose cabinet hinge gets tightened on the spot — a screwdriver, thirty seconds, done. That is Direct Execution. The same contractor asked to restructure the kitchen layout does not start swinging a hammer. She produces a work order: demo this wall, relocate these outlets, move the gas line, tile this floor, install these cabinets. The homeowner reviews and approves each line. Only then do crews mobilize. That is Plan Mode.

The construction analogy highlights the multi-file refactor case especially well. A kitchen restructure touches plumbing, electrical, gas, framing, and finish — multiple "files," each with dependencies on the others. Starting demo without a plan risks cutting through a gas line mid-swing. The 45+ file monolith-to-microservices restructure in the CCA-F sample questions is exactly a kitchen restructure: too many dependencies to freestyle.

Which Analogy to Reach For on Exam Day

• For scenarios testing mode selection by task size → kitchen (short-order vs banquet).
• For scenarios testing discovery isolation (Explore subagent) → kitchen walk-in inventory.
• For scenarios testing the cost of skipping planning on ambiguous work → open-book essay.
• For scenarios testing multi-file blast radius → construction work order.

Plan Mode and the Claude Code Feature Surface

Plan Mode does not live in isolation — it composes with other Claude Code features the CCA-F exam tests across Domain 3.

Interaction With CLAUDE.md

Project CLAUDE.md can mandate plan mode for the repository. User CLAUDE.md can mandate plan mode globally. Directory CLAUDE.md can override either for a specific subtree. The hierarchy is the same three-level hierarchy Task 3.1 tests, applied to plan-mode defaults.

Interaction With Slash Commands

A custom slash command defined in .claude/commands/ can explicitly invoke plan mode as part of its template. A /refactor command, for example, might hard-code "Produce a plan before any edits" in its body, ensuring every invocation of /refactor triggers planning regardless of default configuration.

Interaction With Subagents

Subagents can have their own plan-mode defaults distinct from the coordinator. An Explore subagent typically runs in direct execution (its "actions" are read-only tool calls), while a refactor subagent might default to plan mode. The context: fork skill pattern preserves this separation.

Interaction With Path-Specific Rules

A .claude/rules/ YAML file can encode path-based plan-mode mandates: "files matching migrations/** require a plan before any write." This is the production-grade mechanism for hybrid routing.

Common Exam Traps — Plan Mode Is Not a Separate Model; Direct Execution Is Not Less Capable

The CCA-F exam aggressively exploits three trap patterns tied to Plan Mode vs Direct Execution.

Trap 1: "Plan Mode Is a Separate Claude Model"

Answer choices sometimes imply that Plan Mode routes the request to a different, more powerful model. It does not. The same model answers in both modes. Plan Mode is a workflow discipline, not a model variant. If an answer choice says "plan mode uses a larger model," it is wrong.

Trap 2: "Direct Execution Is Less Capable"

Direct Execution does not reduce Claude's capability. It removes the mandatory pre-approval gate. An answer choice claiming "direct execution cannot handle multi-file tasks" or "direct execution skips testing" is wrong. Claude in direct execution mode can still test, roll back, escalate, or ask clarifying questions — it just does not pre-commit to a plan.

Trap 3: "Start Direct, Switch to Plan If Complexity Emerges"

This sounds reasonable but is wrong when the scenario already states the complexity. If the task is described as "monolith-to-microservices restructure across 45+ files," the complexity is known up front. Starting in direct execution and switching later wastes context on the discovery work that direct execution performed before the mode switch. Plan Mode should start at the beginning when complexity is already in the requirements.

Trap 4: "Plan Mode Is Always Safer"

Plan Mode on a single-file bug fix adds latency without adding safety. The CCA-F sample Q5 pattern (adding a date validation conditional) deliberately tempts candidates to "play it safe" with plan mode. The exam marks that choice wrong.

Trap 5: "Plan Mode Works in Non-Interactive CI"

Interactive plan mode requires a user present to approve. In CI pipelines running with -p, interactive plan mode breaks automation. Candidates who design CI workflows around interactive plan mode produce pipelines that hang forever.

Practice Anchors — Task 3.4 Scenario Questions

CCA-F questions tied to Plan Mode vs Direct Execution cluster in two scenario families.

Code Generation With Claude Code — The Canonical Scenario

The Code Generation scenario is where Plan Mode vs Direct Execution is tested most heavily. Sample Q5 from the exam guide uses this shape:

A development team needs to restructure a monolithic Python application into a microservices architecture. The work will affect approximately 45 files across authentication, billing, and reporting modules. Multiple valid decomposition strategies exist, and the team wants to review the approach before any code changes occur. Which Claude Code workflow is most appropriate?

The correct answer is Plan Mode. The task signals — large-scale change, multiple valid approaches, architectural decision, multi-file scope, explicit "review before changes" requirement — collectively match every plan-mode trigger.

A paired sample question inverts the shape:

A developer has a failing unit test that points directly at date-validator.ts line 87. The stack trace identifies a missing null check before a conditional. Which Claude Code workflow is most appropriate?

The correct answer is Direct Execution. Single-file, clear stack trace, well-scoped — the planning overhead would exceed the fix. "Switch to plan mode just in case" is wrong.

Developer Productivity With Claude — The Hybrid Scenario

The Developer Productivity scenario tests the Explore-then-Plan-then-Execute composition:

A developer is planning a library migration from requests to httpx across a large Python codebase. The number of affected call sites is unknown, and the migration involves some behavior changes (timeout semantics, response object shape). Which combination of Claude Code features is most appropriate?

The correct answer combines an Explore subagent to map call sites without flooding main context, Plan Mode to review the migration approach once the surface is known, and Direct Execution to implement the plan step-by-step after approval. Answer choices that pick any single mode in isolation are wrong — the scenario explicitly calls for the three-phase pattern.

Claude Code for Continuous Integration — The Non-Interactive Trap

The CI scenario often tests plan mode's incompatibility with non-interactive pipelines:

A team runs Claude Code in GitHub Actions using the -p flag to automate dependency updates. A project-wide CLAUDE.md setting currently mandates plan mode for all changes. The pipeline is hanging. What is the root cause?

The correct answer is that interactive plan mode requires user approval, which is unavailable in non-interactive CI. The fix is to relax the plan-mode mandate for CI contexts or to supply approval programmatically. Candidates who answer "the -p flag is wrong" or "use a different model" miss the interaction.

Plan Mode vs Direct Execution Frequently Asked Questions (FAQ)

When should I choose Plan Mode over Direct Execution on the CCA-F exam?

Choose Plan Mode when the scenario describes high blast radius (migrations, infrastructure, security-critical code), architectural ambiguity (multiple valid approaches), multi-file scope (especially when the file count is stated as large), or unfamiliar codebase context. The canonical trigger phrase is "multi-file" or an explicit file count like "45+ files." Choose Direct Execution when the scenario describes a single-file, reversible, well-scoped change — typified by a clear stack trace, an unambiguous spec, or a one-line conditional. When the scenario explicitly states complexity up front, do not start in Direct Execution and plan to "switch if complexity emerges" — the complexity is already known and plan mode should start at the beginning.

Is Plan Mode always the safer choice?

No — and this is the single most common CCA-F trap on Task 3.4. Plan Mode on a single-file bug fix adds latency and token overhead without adding safety, because the fix is already trivial to verify and trivial to revert. The CCA-F sample Q5 pattern deliberately pairs a well-scoped task with a "switch to plan mode just to be safe" distractor; that distractor is wrong. Plan Mode is an architectural match for blast radius, not a universal best practice.

How does Plan Mode interact with the -p flag for non-interactive CI pipelines?

Plan Mode is fundamentally interactive — it requires a user to approve, amend, or reject the plan. The -p flag runs Claude Code non-interactively in CI, where no user is present. If a project CLAUDE.md mandates plan mode and the same project is invoked with -p, the pipeline will hang waiting for approval that never comes. Teams that want automated Claude Code in CI should either disable plan mode in CI contexts, use a CI-specific CLAUDE.md path that omits the plan mandate, or supply approval programmatically via the SDK.

What is the Explore subagent and when do I use it with Plan Mode?

The Explore subagent is a specialized Claude Code subagent whose role is to perform verbose discovery work — recursive file reads, call-graph traces, pattern searches — in an isolated context and return a compact summary to the main conversation. You pair the Explore subagent with Plan Mode when the task is complex enough to warrant planning but large enough that discovery would exhaust the main context window. The canonical three-phase pattern is: spawn an Explore subagent to map the surface, switch into Plan Mode to produce an execution plan from the summary, then execute the approved plan in Direct Execution. Library migrations and large refactors are the canonical use cases.

Does Plan Mode use a different Claude model than Direct Execution?

No. Plan Mode and Direct Execution use the same underlying model with the same capabilities. Plan Mode is a workflow discipline that changes when Claude commits to actions — it produces a complete plan up front and pauses for user approval — not a different or "smarter" model. Answer choices on the CCA-F exam that imply Plan Mode routes to a larger model are wrong.

Can Plan Mode be set as the default behavior for a project?

Yes. A project-level CLAUDE.md can contain a directive like "Always produce a plan before any filesystem-mutating change" to force plan mode as the default for all tasks in the repository. Because CLAUDE.md supports a three-level hierarchy (user → project → directory), the default can be relaxed selectively for directories where the median task is low-risk. User-level CLAUDE.md can also set a personal default. Be cautious about always-on plan mode in application repositories where the typical change is a small edit — the ceremony overhead accumulates.

How do I combine Plan Mode with Direct Execution in a single workflow?

The canonical hybrid pattern is the three-phase composition: use an Explore subagent to gather context without flooding the main conversation, then switch into Plan Mode to review the approach with the user, then proceed in Direct Execution to implement the approved plan step-by-step. This pattern appears explicitly in Developer Productivity scenario questions on the CCA-F exam, especially for library migrations and framework upgrades. Selecting any single mode in isolation when the scenario describes all three phases is wrong.

Further Reading

• Claude Certified Architect — Foundations Exam Guide: https://everpath-course-content.s3-accelerate.amazonaws.com/instructor/8lsy243ftffjjy1cx9lm3o2bw/public/1773274827/Claude+Certified+Architect+%E2%80%93+Foundations+Certification+Exam+Guide.pdf
• Plan Mode and Iterative Refinement — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/plan-mode
• Claude Code Features Overview: https://docs.anthropic.com/en/docs/claude-code/overview
• Create Custom Subagents — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/sub-agents
• Context Windows — Claude API Docs: https://docs.anthropic.com/en/docs/build-with-claude/context-windows
• Integrate Claude Code into CI/CD Pipelines: https://docs.anthropic.com/en/docs/claude-code/ci-cd
• Kishor Kukreja — Passed Anthropic's CCA-F 893/1000: https://medium.com/@kishorkukreja/i-passed-anthropics-claude-certified-architect-foundations-exam-with-a-score-of-893-1000-2206c27efd6c

Related ExamHub topics: CLAUDE.md Files — Hierarchy, Scoping, and Modular Organization, Task Decomposition Strategies, Iterative Refinement Techniques, Multi-Step Workflows with Enforcement and Handoff Patterns, Context Management in Large Codebase Exploration.