AnthropicClaude Certified Architect – Foundations2026-101.6 Design task decomposition strategies for complex workflows
Separate file reviews from integration checks
Completed by the knowledge check
Learning objective
Chain predictable, focused review stages with explicit handoffs: file-local analysis followed by cross-file integration checks.
Core idea
A file can look correct in isolation while breaking the system that calls it. Separate a large review into local analysis and an integration pass so each stage answers a different question. The local stage asks whether the changed code works under its stated assumptions. The integration stage asks whether those assumptions agree across boundaries.
The CCAR-F exam guide explicitly names per-file analysis followed by cross-file integration as a way to avoid attention dilution. Anthropic’s prompt-chaining pattern provides the architecture: one stage produces material for the next, and a programmatic gate can check whether that material is ready. See 1.6.1 for choosing the pattern; here the stages are already predictable.
This is more than dividing a long prompt into shorter prompts. Each stage needs a defined input and an output that the next stage can use. Otherwise, the integration pass receives summaries that discard the relationships it was supposed to verify.
How it works
Give each local pass one bounded assignment
Start with the changed file, its relevant diff, and the review criteria. Ask Claude to inspect local control flow, error handling, and changed inputs or outputs. Keep the scope explicit: a local pass should identify assumptions about callers and dependencies rather than claim to certify the whole feature.
In Claude Code, Read reads file contents and Bash can run searches and project checks. Name the files and evidence required; see 1.6.4 for the search-tool availability boundary.
Anthropic’s best practices recommend specific file references and verification criteria rather than vague requests. Apply that guidance to the local pass: ask for the behavior changed, the evidence for any defect, and dependencies the integration reviewer must inspect. A request to “find bugs” alone does not define whether the reviewer must examine compatibility, error semantics, or tests.
A focused pass need not be blind. If a function’s local behavior depends on an imported type, inspect that definition. The boundary concerns the conclusion: the local pass explains the file and its assumptions, while the integration pass establishes whether the surrounding system satisfies them.
Make the handoff carry review evidence
Use a consistent handoff contract across files. For this workflow, useful fields include:
- The reviewed file and the changed function or interface.
- The observed behavior, with a precise source location.
- Each caller or dependency assumption that affects correctness.
- The local finding and its supporting evidence, or an explicit no-finding result.
- The tests inspected or run, their outcomes, and unresolved checks.
These are fields in your review contract, not Claude Code API field names. See 1.3.4 for the broader evidence-handoff discipline. Here the important addition is the boundary assumption: for example, “the caller supplies a value in seconds” lets the integration pass verify a relationship that “timeout logic looks fine” conceals.
Invoke each stage with claude -p when a script owns the chain. --output-format json gives the print-mode output format. For a schema-validated handoff, use --output-format json with --json-schema; the latter requests validated JSON matching your JSON Schema after the agent completes its workflow and is print-mode only. The validated object arrives in the response’s structured_output field alongside request metadata. The script reads that field, checks semantic coverage, and includes the findings in the next stage’s prompt. Schema compliance establishes neither complete patch coverage nor the accuracy of the review.
Anthropic’s chaining pattern lets you add programmatic intermediate checks. Use that gate to compare received file handoffs with the intended review scope. If a pass omitted a changed file or reported it could not inspect a dependency, request the missing analysis before marking the stage complete. An absent finding is not equivalent to a completed review with no finding.
Give integration a relationship-based assignment
The integration pass receives the patch scope, local handoffs, relevant source, and explicit criteria. Ask it to verify caller-callee contracts, shared representations, error propagation, configuration assumptions, and test coverage across the affected path. Reading only local summaries is insufficient when the suspected mismatch requires checking actual source.
The integration pass starts only after the programmatic gate marks the stage complete, and it reads the relevant source as well.
A useful integration question names both sides of the boundary. Does the caller pass the units the callee expects? Does the consumer accept the producer’s missing-value representation? Does an adapter preserve the retry behavior assumed by its caller? These questions concern relationships, rather than another scan for the same local defects.
Keep verification concrete. Anthropic recommends giving Claude a test, build, or other check it can run and asking for the command and result as evidence. For a cross-file mismatch, request the relevant regression test or build check, rather than accept “all files look consistent.” When a check cannot run, the integration report should preserve that unresolved condition.
Focus review on the stated requirements
Anthropic’s guidance for independent review recommends supplying the diff and criteria in a fresh context; the bundled /code-review skill checks the current diff for bugs in a fresh subagent. The guidance also warns that asking a reviewer to find gaps can produce unnecessary work. Direct the integration pass to report defects affecting correctness or the stated requirements, and treat optional improvements separately.
Separate contexts are useful for focus, but do not fix missing inputs. If you delegate either stage through Agent, pass the review criteria and required handoff explicitly; see 1.3.3. A reviewer cannot verify an interface assumption that never reaches its assignment.
Key distinctions and trade-offs
Local correctness versus integration correctness: A calculation can be correct for its documented input while its caller supplies the wrong units. Both passes matter because they test different propositions.
Summary versus handoff: A summary compresses information. A handoff preserves the specific evidence and unresolved relationships needed for the next decision. Concision is useful only while that evidence remains available.
Fresh review versus duplicate review: A fresh integration context reduces accumulated implementation context, but needs a distinct cross-file assignment. Asking every stage to “review everything” recreates attention dilution.
More capacity versus more focus: A larger context window or a stronger model gives the single pass room, not attention. Anthropic’s context-window documentation states that more context isn’t automatically better: as token count grows, accuracy and recall degrade, which it calls context rot. Its context-engineering guidance adds that this emerges across all models. Restructure the review into passes instead of moving the whole patch to a bigger window.
The chain adds invocation and handoff overhead. For a tiny change with one self-contained behavior, a single focused review may suffice. For a multi-file change with known review dimensions, explicit stages make omissions visible and give each pass a tractable job.
Architecture / decision scenario
A code-generation workflow changes a timeout parser, a scheduling service, and a worker adapter. The required behavior is to preserve the same timeout semantics from user configuration through worker execution.
The parser pass reports a value in seconds. The scheduling-service pass finds that its internal arithmetic is consistent and records the unit it assumes. The adapter pass verifies its local conversion code. Each handoff includes source locations and relevant test evidence, so local success does not conceal the boundary assumptions.
After checking that all three handoffs exist, the application invokes an integration pass. It supplies the handoffs and source for the complete path. The reviewer discovers that the scheduler treats the parsed value as milliseconds. None of the isolated calculations proves that the units agree across the call boundary.
The workflow requests a regression check spanning parser to scheduler, reports its result, and repeats the integration check after the correction. It does not ask the adapter reviewer to re-review unrelated logic. The explicit handoff makes the mismatch traceable and the follow-up focused.
Common exam traps
- Declaring the feature correct because every file passed an isolated review.
- Replacing integration analysis with concatenated local summaries.
- Asking each per-file pass to verify cross-file contracts too, although no single pass reads both sides of a boundary.
- Omitting caller assumptions because the local pass found no defect.
- Letting a failed or incomplete file pass count as no findings.
- Asking every stage to inspect the whole patch without distinct criteria.
- Treating JSON transport as proof of complete evidence.
- Switching to a stronger model or a larger context window to cure attention dilution in one pass over many files.
What to remember
Review local behavior first, preserve boundary assumptions in explicit handoffs, then verify the relationships across files. Gate the handoff for coverage and require evidence from the integration check before accepting the feature.
Knowledge check
In CI, every changed file gets a separate claude -p call told to “review this file, including how it affects other files”. A pull request changes the signature of load_rates() in currency.py, checkout.py still calls it the old way, and none of the reports flags the mismatch. The team requires a focused local review of every changed file and verification of cross-file compatibility before acceptance. Which structure gives these responsibilities distinct review scopes?
A local review pass checks a scheduling service whose arithmetic is correct if its input is in milliseconds. An integration pass will later verify the path from the configuration parser through the scheduler. What must the scheduler’s handoff record for that check to work?
A script runs one claude -p --output-format json --json-schema … call per changed file and reads each structured_output. For a patch of five files it receives four schema-valid handoffs; the fifth call reported that it could not read a dependency and returned none. What should the script do before starting the integration pass?
An integration pass told to “review the whole patch and find any gaps” returns a long list that repeats the local findings and adds optional refactors, while the one unit mismatch between two services is buried. How should its assignment change?
References
- Anthropic, Building effective agents
- Anthropic, Best practices for Claude Code
- Anthropic, Tools reference
- Anthropic, CLI reference
- Anthropic, Run Claude Code programmatically
- Anthropic, Context windows
- Anthropic, Effective context engineering for AI agents
- Anthropic, Claude Certified Architect – Foundations Exam Guide