CCAR-F - Claude Code Configuration & Workflows (20% of the exam) - Section 3.2
Create and configure custom slash commands and skills.
Project-scoped commands are shared through version control; user-scoped commands stay personal. Skills carry frontmatter including context, allowed-tools and argument-hint. The fork context option runs a skill in an isolated subagent so verbose output never pollutes the main conversation. Candidates should restrict tool access during skill execution, prompt for missing parameters through argument-hint, and choose between an on-demand skill and always-loaded CLAUDE.md standards.
The Halyard team wrote a project slash command called audit-deps, expecting it to run its dependency audit away from whatever else is in the session. An engineer invokes it 60 turns into a long debugging conversation about a caching bug, and the resulting audit cites files that were read during that debugging thread and repeats a conclusion reached there. The command body itself mentions none of those files. What explains the outcome?
AThe command frontmatter omitted Grep from its allowed tools, so the model fell back on files that had already been read earlier in the conversation.
BCommand bodies are cached per session after their first use, so this invocation replayed output that was captured during the earlier debugging work.
CA slash command body is expanded into the current conversation, so the audit runs with everything already in that context rather than starting from a clean one.check_circle Correct
DSubagent dispatch and slash command invocation share a single context window by design, so no configuration can give the audit a context of its own.
Slash commands expand into the running conversation and inherit its context; reach for a subagent when the work needs isolation. A slash command is a stored prompt, not a separate execution environment. Invoking it inserts the command body into the ongoing conversation, so prior turns, prior file reads and prior conclusions all remain in scope and can be drawn on. Isolation comes from dispatching a subagent with the Task tool, which is given a fresh context and receives only what the dispatching prompt states.
Why A is wrong: Tempting because a narrowed tool list can genuinely change how a command gathers evidence, but a missing search tool would explain thin coverage, not the presence of a prior conclusion that no tool call produced.
Why B is wrong: Tempting because caching is a real mechanism elsewhere on the platform, but command bodies are not replayed from earlier output, and this was the first invocation of the command in the session.
Why C is correct: Correct: invoking a command substitutes its body as a prompt in the running session, so every file and conclusion already present remains visible to the model handling the audit.
Why D is wrong: Tempting because it describes the command half accurately, but it is wrong about subagents: one dispatched with the Task tool does get its own context, which is the mechanism to reach for when isolation is the requirement.
Exam traps in Claude Code Configuration & Workflows
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCAR-F bank for this domain.
Rewrite the command body so the prohibition on shell commands appears in capitals at the top, and add two worked examples showing a compliant survey run end to end.
errorWhy it is wrong: Tempting because clearer instructions and examples do shift model behaviour, but this leaves compliance probabilistic when the requirement is a guarantee, and the existing instruction not to modify files already failed 14 times.
Collapse the two positional placeholders into a single arguments placeholder and let the command work out from the text which value is the endpoint path and which is the branch.
errorWhy it is wrong: Tempting because it removes any ordering requirement from the engineer, but it converts a structural problem into an inference the model has to make on every run, and a branch name that happens to look like a path will still be read as the wrong parameter.
Skill bodies are read only after the first tool call in a session, so early refactoring requests miss the playbook while later ones in the same session pick it up correctly.
errorWhy it is wrong: Tempting because it offers a tidy account of the inconsistency, but skill loading is not sequenced against tool calls, and this would leave the drop on sessions that never refactor unexplained.