3.1 Claude Code Workflows

Configure Claude Code for Repeatability and Safety

Claude Code is Anthropic's agentic command-line coding tool, and the CCA-F treats it as a production system to be configured, not a chatbot. Claude Code Configuration & Workflows is a 20% domain on the exam. A good setup tells Claude which conventions matter, which tools may run without asking, how to validate its work, and when human approval is required. The exam consistently rewards answers that constrain the agent and prove outcomes over answers that grant broad autonomy.

Configuration Surfaces You Must Know

The CLAUDE.md Hierarchy and Precedence

The exam explicitly tests the CLAUDE.md hierarchy. Project memory is layered, and the layers combine, with more specific scopes adding to (and able to override) broader ones:

When Claude works in a subdirectory, the applicable memory is the combination of user, project, and that subdirectory's file, with the most specific (closest) instructions taking precedence on conflicts. A .claudeignore file excludes paths from context the way .gitignore excludes them from git. This layering lets a monorepo give the frontend folder different rules than the backend folder without bloating one giant file.

Project Memory: What Belongs and What Does Not

CLAUDE.md should capture stable conventions: the package manager, the test command, naming rules, directories to avoid, and hard constraints. It should not store secrets or credentials (those belong in environment variables or a secrets manager), nor transient 'remember for this one task' notes. A bloated memory file wastes context budget on every turn — keep it lean and point to detailed docs rather than inlining them. Write instructions for the team and the model: concise, imperative, and unambiguous.

Permissions and Hooks: Gating Risk

Permissions match the blast radius of an action. Read-only tools can be allowed freely; destructive shell actions (rm -rf, git push --force, production deploys) should be set to ask or deny.

Hooks add a deterministic layer the model cannot skip: a PreToolUse hook can block a command that matches a pattern, and a PostToolUse hook can run a linter or pnpm test automatically after edits. Because hooks are plain shell, they execute every time regardless of the model's judgment — that determinism is exactly why the exam favors them for policy enforcement. Hooks also follow exit-code conventions: a non-zero exit from a PreToolUse hook blocks the action, giving you a hard gate the agent cannot reason its way past.

Skills: Triggerable, Packaged Expertise

Skills are folders containing a SKILL.md with frontmatter (a name and a description that acts as the trigger) plus any supporting files. The description sits in context cheaply; Claude loads the full skill only when the task matches the trigger — progressive disclosure. Skills are how teams package and distribute a reusable capability (a house style for slide decks, an internal API runbook) across an organization without inflating every prompt. On the exam, prefer a skill when the knowledge is task-specific and should load on demand, and CLAUDE.md when the rule is a stable always-on convention.

Headless, CI, and the Validation Habit

For headless runs (claude -p "...") and CI pipelines, outputs must be predictable because no human watches each step. Require explicit success criteria, scoped permissions (never blanket --dangerously-skip-permissions in shared CI without sandboxing), and automated validation. Pair every automation path with a concrete command or review step that proves the requested change worked — a build that passes, a test suite that is green, a diff a reviewer approves.

Setup Review Checklist

• Is project memory stable, layered correctly, and free of secrets?
• Are slash commands and subagents scoped to single, repeatable jobs?
• Are skills triggered only when relevant, with clear descriptions?
• Are risky shell and file actions gated by ask/deny or a PreToolUse hook?
• Do hooks run useful, deterministic checks (lint, tests, format)?
• Do MCP servers expose only the tools and resources the task needs (least privilege)?
• Does each unattended path end in a validation step that proves success?

Subagents and MCP: Scope and Least Privilege

Subagents are separate Claude instances with their own system prompt, tool allowlist, and isolated context window, defined in .claude/agents/*.md. They exist to keep a specialist focused — a test-runner subagent that only runs and reports tests, or a code-reviewer that only reads diffs — and to avoid polluting the main conversation's context with low-level detail. The exam favors narrow subagents over one omniscient agent because narrow scope is easier to validate and limits blast radius.

Model Context Protocol (MCP) is the open standard Claude Code uses to connect external tools, data sources, and prompts through MCP servers. The recurring exam principle is least privilege: wire only the servers and expose only the tools a task actually requires. A server that grants write access to a production database when the agent only needs to read schema is a misconfiguration the exam will flag. Treat MCP tool exposure exactly like API scopes — minimal, explicit, auditable.

Mapping Configuration to Risk

The through-line for the entire chapter is the same as Chapter 2: prefer the simplest, most controllable design that still does the job, gate anything risky, and end every automated path with a concrete check that proves the work actually succeeded.