S4 · Developer Productivity with Claude

spans 65% of the blueprint D1 27% D2 18% D3 20% ~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
D1 Agentic Architecture & Orchestration	27%	16.2	7	9
D2 Tool Design & MCP Integration	18%	10.8	5	6
D3 Claude Code Configuration & Workflows	20%	12.0	6	5

Task statements in play 9 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
1.1	Design and implement agentic loops for autonomous task execution Keys The agentic loop lifecycle: sending requests to Claude, inspecting stop_reason ("tool_use" vs "end_turn"), executing requested tools, and returning results for the next iteration How tool results are appended to conversation history so the model can reason about the next action The distinction between model-driven decision-making (Claude reasons about which tool to call next based on context) and pre-configured decision trees or tool sequences Implementing agentic loop control flow that continues when stop_reason is "tool_use" and terminates when stop_reason is "end_turn" Adding tool results to conversation context between iterations so the model can incorporate new information into its reasoning Avoiding anti-patterns such as parsing natural language signals to determine loop termination, setting arbitrary iteration caps as the primary stopping mechanism, or checking for assistant text content as a completion indicator Anti-patterns parsing natural language signals to determine loop termination setting arbitrary iteration caps as the primary stopping mechanism checking for assistant text content as a completion indicator	D1	3
1.3	Configure subagent invocation, context passing, and spawning Keys The Task tool as the mechanism for spawning subagents, and the requirement that allowedTools must include "Task" for a coordinator to invoke subagents That subagent context must be explicitly provided in the prompt—subagents do not automatically inherit parent context or share memory between invocations The AgentDefinition configuration including descriptions, system prompts, and tool restrictions for each subagent type Fork-based session management for exploring divergent approaches from a shared analysis baseline Including complete findings from prior agents directly in the subagent's prompt (e.g., passing web search results and document analysis outputs to the synthesis subagent) Using structured data formats to separate content from metadata (source URLs, document names, page numbers) when passing context between agents to preserve attribution Spawning parallel subagents by emitting multiple Task tool calls in a single coordinator response rather than across separate turns Designing coordinator prompts that specify research goals and quality criteria rather than step-by-step procedural instructions, to enable subagent adaptability	D1	3
1.6	Design task decomposition strategies for complex workflows Keys When to use fixed sequential pipelines (prompt chaining) versus dynamic adaptive decomposition based on intermediate findings Prompt chaining patterns that break reviews into sequential steps (e.g., analyze each file individually, then run a cross-file integration pass) The value of adaptive investigation plans that generate subtasks based on what is discovered at each step Selecting task decomposition patterns appropriate to the workflow: prompt chaining for predictable multi-aspect reviews, dynamic decomposition for open-ended investigation tasks Splitting large code reviews into per-file local analysis passes plus a separate cross-file integration pass to avoid attention dilution Decomposing open-ended tasks (e.g., "add comprehensive tests to a legacy codebase") by first mapping structure, identifying high-impact areas, then creating a prioritized plan that adapts as dependencies are discovered	D1	5
2.1	Design effective tool interfaces with clear descriptions and boundaries Keys Tool descriptions as the primary mechanism LLMs use for tool selection; minimal descriptions lead to unreliable selection among similar tools The importance of including input formats, example queries, edge cases, and boundary explanations in tool descriptions How ambiguous or overlapping tool descriptions cause misrouting (e.g., analyze_content vs analyze_document with near-identical descriptions) The impact of system prompt wording on tool selection: keyword-sensitive instructions can create unintended tool associations Writing tool descriptions that clearly differentiate each tool's purpose, expected inputs, outputs, and when to use it versus similar alternatives Renaming tools and updating descriptions to eliminate functional overlap (e.g., renaming analyze_content to extract_web_results with a web-specific description) Splitting generic tools into purpose-specific tools with defined input/output contracts (e.g., splitting a generic analyze_document into extract_data_points, summarize_content, and verify_claim_against_source) Reviewing system prompts for keyword-sensitive instructions that might override well-written tool descriptions	D2	3
2.3	Distribute tools appropriately across agents and configure tool choice Keys The principle that giving an agent access to too many tools (e.g., 18 instead of 4-5) degrades tool selection reliability by increasing decision complexity Why agents with tools outside their specialization tend to misuse them (e.g., a synthesis agent attempting web searches) Scoped tool access: giving agents only the tools needed for their role, with limited cross-role tools for specific high-frequency needs tool_choice configuration options: "auto", "any", and forced tool selection ({"type": "tool", "name": "..."}) Restricting each subagent's tool set to those relevant to its role, preventing cross-specialization misuse Replacing generic tools with constrained alternatives (e.g., replacing fetch_url with load_document that validates document URLs) Providing scoped cross-role tools for high-frequency needs (e.g., a verify_fact tool for the synthesis agent) while routing complex cases through the coordinator Using tool_choice forced selection to ensure a specific tool is called first (e.g., forcing extract_metadata before enrichment tools), then processing subsequent steps in follow-up turns Setting tool_choice: "any" to guarantee the model calls a tool rather than returning conversational text	D2	4
2.4	Integrate MCP servers into Claude Code and agent workflows Keys MCP server scoping: project-level (.mcp.json) for shared team tooling vs user-level (~/.claude.json) for personal/experimental servers Environment variable expansion in .mcp.json (e.g., ${GITHUB_TOKEN}) for credential management without committing secrets That tools from all configured MCP servers are discovered at connection time and available simultaneously to the agent MCP resources as a mechanism for exposing content catalogs (e.g., issue summaries, documentation hierarchies, database schemas) to reduce exploratory tool calls Configuring shared MCP servers in project-scoped .mcp.json with environment variable expansion for authentication tokens Configuring personal/experimental MCP servers in user-scoped ~/.claude.json Enhancing MCP tool descriptions to explain capabilities and outputs in detail, preventing the agent from preferring built-in tools (like Grep) over more capable MCP tools Choosing existing community MCP servers over custom implementations for standard integrations (e.g., Jira), reserving custom servers for team-specific workflows Exposing content catalogs as MCP resources to give agents visibility into available data without requiring exploratory tool calls	D2	3
2.5	Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively Keys Grep for content search (searching file contents for patterns like function names, error messages, or import statements) Glob for file path pattern matching (finding files by name or extension patterns) Read/Write for full file operations; Edit for targeted modifications using unique text matching When Edit fails due to non-unique text matches, using Read + Write as a fallback for reliable file modifications Selecting Grep for searching code content across a codebase (e.g., finding all callers of a function, locating error messages) Selecting Glob for finding files matching naming patterns (e.g., */.test.tsx) Using Read to load full file contents followed by Write when Edit cannot find unique anchor text Building codebase understanding incrementally: starting with Grep to find entry points, then using Read to follow imports and trace flows, rather than reading all files upfront Tracing function usage across wrapper modules by first identifying all exported names, then searching for each name across the codebase	D2	4
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.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

The lab

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

Primary domains: D1 Agentic Architecture & Orchestration (27%) · D2 Tool Design & MCP Integration (18%) · D3 Claude Code Configuration & Workflows (20%) Spans 65% of the blueprint — the highest of any single scenario. Build this lab first.

Brief

A developer-productivity agent built on the Claude Agent SDK. It helps engineers explore unfamiliar codebases, understand legacy systems, generate boilerplate, and automate repetitive tasks. It uses the built-in tools (Read, Write, Bash, Grep, Glob) and integrates Model Context Protocol servers.

This is the scenario closest to what Gnar already ships, which makes it both the cheapest lab to build and the most convincing one to demo.

Task statements in play

ID	Statement
1.1	Design and implement agentic loops for autonomous task execution
1.3	Configure subagent invocation, context passing, and spawning
1.6	Design task decomposition strategies for complex workflows
2.1	Design effective tool interfaces with clear descriptions and boundaries
2.3	Distribute tools appropriately across agents and configure tool choice
2.4	Integrate MCP servers into Claude Code and agent workflows
2.5	Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively
3.1	Configure CLAUDE.md files with appropriate hierarchy, scoping, and modular organization
3.5	Apply iterative refinement techniques for progressive improvement

The decisions it tests

Community MCP server or a custom one. The guide's rule here is narrow and specific: choose existing community MCP servers over custom implementations for standard integrations (its example is Jira), reserving custom servers for team-specific workflows. Scoping follows the same axis — project-level .mcp.json for shared team tooling, user-level ~/.claude.json for personal/experimental servers.

Two adjacent choices the guide states separately, and does not fold into one framework:

Skill or CLAUDE.md. Skills are on-demand invocation for task-specific workflows; CLAUDE.md is always-loaded universal standards. That is the guide's framing of the choice — note that it is skills against CLAUDE.md, not skills against tools.
MCP tool or built-in. The guide's concern is the opposite of wrapping: enhance MCP tool descriptions to explain capabilities and outputs in detail, to prevent the agent preferring a built-in (like Grep) over a more capable MCP tool.

> Ours, not the guide's. An earlier version of this page taught a four-way "built-in vs custom tool > vs Skill vs MCP server" decision with reuse and ownership as the deciding questions. That framework > is our heuristic; it is nowhere in the guide, and no exam item is written against it. It is still a > reasonable way to think, and this being the "build first" lab we do apply it — but the three bullets > above are the guide's actual content, and they are what an item can test.

Tool descriptions as the selection mechanism. The model chooses tools from their descriptions, so minimal or overlapping descriptions cause unreliable selection. analyze_content and analyze_document with near-identical descriptions is the guide's own example of misrouting. Fixes: rename to express the real boundary, add input formats and example queries, or split a generic tool into purpose-specific ones with defined I/O contracts.

Decomposing open-ended work. "Understand this legacy system" has no fixed pipeline. Map the structure first, identify high-impact areas, then build a prioritized plan that adapts as dependencies surface — rather than committing to a fixed sequence up front. Contrast with a predictable multi-aspect review, where prompt chaining is the better fit.

Where the loop stops. stop_reason is tool_use to continue, end_turn to terminate. Not the presence of assistant text, not a natural-language "I'm done", not an iteration cap as the primary control.

Reference build

A codebase-exploration agent pointed at this repo:

Agent SDK loop driven by stop_reason, tool results appended to history each iteration
Built-ins for traversal, plus one MCP server exposing a capability the built-ins genuinely lack
Add one deliberately overlapping tool pair, observe the misrouting, then fix it by splitting and renaming. Demonstrate the failure — do not describe it
A CLAUDE.md showing hierarchy and scoping, with a note on what belongs at each level

Traps

Scale over design — "use a larger model so it picks the right tool" instead of fixing the descriptions.
Hope over enforcement — adding "please use the correct tool" to the system prompt instead of removing the ambiguity.
Writing a custom MCP server for a standard integration that already has a community one — the guide reserves custom servers for team-specific workflows.
Handing the agent every tool available. Too many tools (the guide's example: 18 instead of 4-5) degrades tool selection reliability by increasing decision complexity.
Assuming a subagent inherits the parent's context. It does not — see s3.md.