S2 · Code Generation with Claude Code

spans 35% of the blueprint D3 20% D5 15% ~15 items per lab on the exam 20 items in the bank

Domains this lab exercises

Expected items apply the blueprint weight to a 60-item exam. Bank items are what exists for this lab today — a coverage figure, never a score.

Domain	Weight	Expected items	Statements	Bank items for this lab
D3 Claude Code Configuration & Workflows	20%	12.0	6	12
D5 Context Management & Reliability	15%	9.0	6	8

Task statements in play 7 of 30

Each statement is a published objective; every practice item on this site cites one. Expand a row for the guide's key facts and, where the guide names them, the anti-patterns that supply that statement's distractors.

ID	Statement	Domain	Bank items
3.1	Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization Keys The CLAUDE.md configuration hierarchy: user-level (~/.claude/CLAUDE.md), project-level (.claude/CLAUDE.md or root CLAUDE.md), and directory-level (subdirectory CLAUDE.md files) That user-level settings apply only to that user—instructions in ~/.claude/CLAUDE.md are not shared with teammates via version control The @import syntax for referencing external files to keep CLAUDE.md modular (e.g., importing specific standards files relevant to each package) .claude/rules/ directory for organizing topic-specific rule files as an alternative to a monolithic CLAUDE.md Diagnosing configuration hierarchy issues (e.g., a new team member not receiving instructions because they're in user-level rather than project-level configuration) Using @import to selectively include relevant standards files in each package's CLAUDE.md based on maintainer domain knowledge Splitting large CLAUDE.md files into focused topic-specific files in .claude/rules/ (e.g., testing.md, api-conventions.md, deployment.md) Claude Certification Program Exam guide Using the /memory command to verify which memory files are loaded and diagnose inconsistent behavior across sessions	D3	4
3.2	Create and configure custom slash commands and skills Keys Project-scoped commands in .claude/commands/ (shared via version control) vs user-scoped commands in ~/.claude/commands/ (personal) Skills in .claude/skills/ with SKILL.md files that support frontmatter configuration including context: fork, allowed-tools, and argument-hint The context: fork frontmatter option for running skills in an isolated sub-agent context, preventing skill outputs from polluting the main conversation Personal skill customization: creating personal variants in ~/.claude/skills/ with different names to avoid affecting teammates Creating project-scoped slash commands in .claude/commands/ for team-wide availability via version control Using context: fork to isolate skills that produce verbose output (e.g., codebase analysis) or exploratory context (e.g., brainstorming alternatives) from the main session Configuring allowed-tools in skill frontmatter to restrict tool access during skill execution (e.g., limiting to file write operations to prevent destructive actions) Using argument-hint frontmatter to prompt developers for required parameters when they invoke the skill without arguments Choosing between skills (on-demand invocation for task-specific workflows) and CLAUDE.md (always-loaded universal standards)	D3	4
3.3	Apply path-specific rules for conditional convention loading Keys .claude/rules/ files with YAML frontmatter paths fields containing glob patterns for conditional rule activation How path-scoped rules load only when editing matching files, reducing irrelevant context and token usage The advantage of glob-pattern rules over directory-level CLAUDE.md files for conventions that span multiple directories (e.g., test files spread throughout a codebase) Claude Certification Program Exam guide Creating .claude/rules/ files with YAML frontmatter path scoping (e.g., paths: ["terraform/*/"]) so rules load only when editing matching files Using glob patterns in path-specific rules to apply conventions to files by type regardless of directory location (e.g., */.test.tsx for all test files) Choosing path-specific rules over subdirectory CLAUDE.md files when conventions must apply to files spread across the codebase	D3	4
3.4	Determine when to use plan mode vs direct execution Keys Plan mode is designed for complex tasks involving large-scale changes, multiple valid approaches, architectural decisions, and multi-file modifications Direct execution is appropriate for simple, well-scoped changes (e.g., adding a single validation check to one function) Plan mode enables safe codebase exploration and design before committing to changes, preventing costly rework The Explore subagent for isolating verbose discovery output and returning summaries to preserve main conversation context Selecting plan mode for tasks with architectural implications (e.g., microservice restructuring, library migrations affecting 45+ files, choosing between integration approaches with different infrastructure requirements) Selecting direct execution for well-understood changes with clear scope (e.g., a single-file bug fix with a clear stack trace, adding a date validation conditional) Using the Explore subagent for verbose discovery phases to prevent context window exhaustion during multi-phase tasks Combining plan mode for investigation with direct execution for implementation (e.g., planning a library migration, then executing the planned approach)	D3	4
3.5	Apply iterative refinement techniques for progressive improvement Keys Concrete input/output examples as the most effective way to communicate expected transformations when prose descriptions are interpreted inconsistently Claude Certification Program Exam guide Test-driven iteration: writing test suites first, then iterating by sharing test failures to guide progressive improvement The interview pattern: having Claude ask questions to surface considerations the developer may not have anticipated before implementing When to provide all issues in a single message (interacting problems) versus fixing them sequentially (independent problems) Providing 2-3 concrete input/output examples to clarify transformation requirements when natural language descriptions produce inconsistent results Writing test suites covering expected behavior, edge cases, and performance requirements before implementation, then iterating by sharing test failures Using the interview pattern to surface design considerations (e.g., cache invalidation strategies, failure modes) before implementing solutions in unfamiliar domains Providing specific test cases with example input and expected output to fix edge case handling (e.g., null values in migration scripts) Addressing multiple interacting issues in a single detailed message when fixes interact, versus sequential iteration for independent issues	D3	5
5.1	Manage conversation context to preserve critical information across long interactions Keys Progressive summarization risks: condensing numerical values, percentages, dates, and customer-stated expectations into vague summaries The "lost in the middle" effect: models reliably process information at the beginning and end of long inputs but may omit findings from middle sections How tool results accumulate in context and consume tokens disproportionately to their relevance (e.g., 40+ fields per order lookup when only 5 are relevant) The importance of passing complete conversation history in subsequent API requests to maintain conversational coherence Extracting transactional facts (amounts, dates, order numbers, statuses) into a persistent "case facts" block included in each prompt, outside summarized history Extracting and persisting structured issue data (order IDs, amounts, statuses) into a separate context layer for multi-issue sessions Trimming verbose tool outputs to only relevant fields before they accumulate in context (e.g., keeping only return-relevant fields from order lookups) Placing key findings summaries at the beginning of aggregated inputs and organizing detailed results with explicit section headers to mitigate position effects Requiring subagents to include metadata (dates, source locations, methodological context) in structured outputs to support accurate downstream synthesis Modifying upstream agents to return structured data (key facts, citations, relevance scores) instead of verbose content and reasoning chains when downstream agents have limited context budgets	D5	4
5.4	Manage context effectively in large codebase exploration Keys Context degradation in extended sessions: models start giving inconsistent answers and referencing "typical patterns" rather than specific classes discovered earlier The role of scratchpad files for persisting key findings across context boundaries Subagent delegation for isolating verbose exploration output while the main agent coordinates high-level understanding Structured state persistence for crash recovery: each agent exports state to a known location, and the coordinator loads a manifest on resume Spawning subagents to investigate specific questions (e.g., "find all test files," "trace refund flow dependencies") while the main agent preserves high-level coordination Having agents maintain scratchpad files recording key findings, referencing them for subsequent questions to counteract context degradation Summarizing key findings from one exploration phase before spawning sub-agents for the next phase, injecting summaries into initial context Designing crash recovery using structured agent state exports (manifests) that the coordinator loads on resume and injects into agent prompts Using /compact to reduce context usage during extended exploration sessions when context fills with verbose discovery output	D5	5

The lab

Rendered from certs/ccar-f-architect-foundations/scenarios/s2.md — the lab document is the source, this page is a view of it.

Primary domains: D3 Claude Code Configuration & Workflows (20%) · D5 Context Management & Reliability (15%) — spans 35%

Brief

Claude Code used to accelerate software development — code generation, refactoring, debugging, and documentation. It must be integrated into the development workflow with custom slash commands and CLAUDE.md configuration, and the candidate must understand when to use plan mode versus direct execution.

Task statements in play

ID	Statement
3.1	Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization
3.2	Create and configure custom slash commands and skills
3.3	Apply path-specific rules for conditional convention loading
3.4	Determine when to use plan mode vs direct execution
3.5	Apply iterative refinement techniques for progressive improvement
5.1	Manage conversation context to preserve critical information across long interactions
5.4	Manage context effectively in large codebase exploration

The decisions it tests

The CLAUDE.md hierarchy, and what belongs at each level. The guide names three levels: user-level (~/.claude/CLAUDE.md), project-level (.claude/CLAUDE.md or root CLAUDE.md), and directory-level (subdirectory CLAUDE.md files). User-level settings apply only to that user — instructions in ~/.claude/CLAUDE.md are not shared with teammates via version control, which is the guide's own diagnostic for "the new team member never got the rule". Modularity has two named mechanisms: @import for referencing external files, and the .claude/rules/ directory for topic-specific rule files as an alternative to a monolithic CLAUDE.md. Use /memory to verify which memory files are actually loaded.

Path-specific rules are glob-scoped, not subtree-scoped. .claude/rules/ files take YAML frontmatter paths fields containing glob patterns — literally paths: ["terraform/**/*"] — and load only when editing matching files. The guide's stated advantage of glob-pattern rules over directory-level CLAUDE.md files is precisely for conventions that span multiple directories, e.g. **/*.test.tsx for all test files wherever they live. Reading this as "conditional loading for a subtree" gets the mechanism backwards: a subtree is what a directory-level CLAUDE.md already does.

Plan mode versus direct execution. Plan mode is designed for complex tasks involving large-scale changes, multiple valid approaches, architectural decisions, and multi-file modifications; it enables safe codebase exploration and design before committing to changes, preventing costly rework. Direct execution is appropriate for simple, well-scoped changes — the guide's example is adding a single validation check to one function. The two combine: plan mode for investigation, direct execution for implementation. Also in 3.4: the Explore subagent, for isolating verbose discovery output and returning summaries so the main conversation's context survives a multi-phase task.

Ours: we read this as "commit the rule, don't hold a preference" — a written decision rule is what the lab builds. That framing is ours; the four triggers above are the guide's.

Commands and skills — scope, then frontmatter. What task statement 3.2 actually contains: project-scoped commands in .claude/commands/ (shared via version control) vs user-scoped commands in ~/.claude/commands/ (personal); skills in .claude/skills/ with SKILL.md files whose frontmatter supports context: fork, allowed-tools, and argument-hint; context: fork for running a skill in an isolated sub-agent context so verbose skill output does not pollute the main conversation; allowed-tools to restrict tool access during skill execution; argument-hint to prompt for required parameters when the skill is invoked without arguments; and personal variants in ~/.claude/skills/ under different names to avoid affecting teammates.

The choice the guide poses is skills versus CLAUDE.md — skills for on-demand invocation of task-specific workflows, CLAUDE.md for always-loaded universal standards. It is not framed as slash commands versus skills. An earlier version of this page said choosing between commands and skills "is task statement 3.2's whole content"; that was our inference and it was wrong on both counts.

Session state is a real design surface. Note the domain, though: session resumption and forking are task statement 1.7, published under D1 — which is not a primary domain of S2, so an S2 draw cannot test them. Read this for the mechanism behind the lab; the context consequences are what 5.1 and 5.4 cover.

Named session resumption using --resume <session-name> continues a specific prior conversation.
fork_session creates independent branches from a shared analysis baseline to explore divergent approaches — the guide's examples are comparing two testing strategies or refactoring approaches from a shared codebase analysis.
Inform a resumed session about specific file changes for targeted re-analysis, rather than requiring full re-exploration.
Starting a new session with a structured summary is more reliable than resuming with stale tool results. Choose resumption when prior context is mostly valid, and start fresh with an injected summary when prior tool results are stale.

Reference build

The repo's own .claude/ directory is the teaching artifact — it is more convincing than a toy:

A CLAUDE.md demonstrating hierarchy and scoping, with a note on why each rule sits where it does
Path-specific rules loading conventions for one subtree only
Two custom slash commands, plus one skill, with a written rationale for the split
A short, explicit plan-mode-vs-direct rule committed as project convention
A worked --resume and fork_session example, and a documented case where starting fresh with a summary was the better call

Traps

Putting everything in one giant CLAUDE.md — context is a budget.
Plan mode as a blanket habit, or never using it. Both fail the "state the rule" test.
Resuming a session after significant file changes without telling the agent what moved.
Truncate over structure — dropping history to save context instead of compacting it or isolating work into a subagent.