Slash commands and skills: CCAR-F task statement 3.2

CCAR-F · Claude Code Configuration & Workflows (20% of the exam)

Task statement 3.2 sits in Claude Code Configuration & Workflows, 20% of the CCAR-F exam. It tests where you put a reusable workflow so the right people get it, and how the frontmatter in SKILL.md controls the way a skill runs.

What the official guide covers

The Claude Certified Architect Foundations exam guide (version 1.0, effective July 2026) lists this under task statement 3.2, "Create and configure custom slash commands and skills":

Knowledge of	Skills in
Project commands in `.claude/commands/` are shared through version control; user commands in `~/.claude/commands/` are personal	Creating project commands in `.claude/commands/` so the whole team gets them
Skills live in `.claude/skills/` as `SKILL.md` files with frontmatter such as `context: fork`, `allowed-tools` and `argument-hint`	Using `context: fork` to keep verbose output (codebase analysis) or exploratory output (brainstorming) out of the main session
`context: fork` runs a skill in an isolated subagent so its output does not pollute the main conversation	Setting `allowed-tools` in frontmatter to control which tools a skill uses
Personal variants go in `~/.claude/skills/` under a different name so teammates are not affected	Using `argument-hint` so developers know which parameters a skill expects
	Choosing a skill (loaded on demand for one task) or CLAUDE.md (loaded every session for universal standards)

Where commands and skills live

Custom commands and skills are now one mechanism. A file at .claude/commands/review.md and a skill at .claude/skills/review/SKILL.md both create /review, and both work the same way. Existing command files keep working. A skill is a folder, so it can also hold templates and scripts, and Claude can load it on its own when the task matches its description.

Scope	Path	Who gets it
Project	`.claude/commands/<name>.md` or `.claude/skills/<name>/SKILL.md`, committed	Everyone who clones or pulls the repository
Personal	`~/.claude/commands/<name>.md` or `~/.claude/skills/<name>/SKILL.md`	You, in every project on your machine
Plugin	`<plugin>/skills/<name>/SKILL.md`	Anyone with the plugin enabled, as `/plugin-name:skill-name`

When two skills share a name, a personal skill wins over a project skill, and a skill wins over a command file. Your personal copy never reaches teammates, but if it has the same name as the team's skill it hides the team version from you. Give a personal variant its own name, such as review-quick.

How a skill loads

Claude Code keeps each skill's description in context on every turn, so Claude knows the skill exists. The full SKILL.md content loads only when the skill is invoked: when you type /name, or when Claude decides the skill fits the task.

That is the difference the exam tests between skills and CLAUDE.md. CLAUDE.md loads at the start of every session, so it suits standards that apply to all work. A skill costs almost nothing until someone needs it, so it suits workflows used only sometimes. For how CLAUDE.md files are layered, see 3.1 CLAUDE.md hierarchy.

Two fields control who can start a skill. disable-model-invocation: true means only a person can run it, which suits workflows with side effects such as a deploy. user-invocable: false hides it from the / menu so only Claude can load it, which suits background knowledge.

Because Claude picks a skill by comparing the task with its description, the description is the trigger. "Helps with tests" rarely fires. "Run after any refactor: runs the test suite, reads the diff and reports pass or fail with evidence" fires when it should. Put the main use case first, because long descriptions are cut short in the skill listing.

What a skill folder can hold

SKILL.md is the only required file. Keep it short and move the depth into the folder:

.claude/skills/verify-change/
|-- SKILL.md          steps and when to use them
|-- reference.md      detailed checks; Claude reads it only when a step needs it
`-- scripts/
    `-- check.sh      Claude runs it; its source is not loaded into context

Link reference.md from SKILL.md so Claude knows it exists. Call bundled scripts through ${CLAUDE_SKILL_DIR}, which Claude Code replaces with the skill's own folder, and scripts kept elsewhere in the repository through ${CLAUDE_PROJECT_DIR}, the project root. Both resolve on every machine. A path into the author's home directory, written in full or with ~, installs fine for teammates and then fails the first time they run the skill. If a step needs an environment variable, name it in the skill and check it first, so a missing one fails at the start, not halfway through.

A verification skill is a good first team skill: run the tests, read the diff, check that no test was loosened to make it pass, and report the result with the evidence. A useful test for any procedure: if you have typed the same multi-step instruction twice, make it a skill.

A skill with the frontmatter the exam names

---
name: map-dependencies
description: Map which modules import a package and summarise how they use it. Use before upgrading or removing a dependency.
argument-hint: [package-name]
context: fork
agent: Explore
allowed-tools: Read Grep Glob
---

Find every module that imports $ARGUMENTS.
For each one, list the file, the functions it calls and any wrapper module in between.
Return a table of at most 30 rows and a three-line summary. Do not paste whole files.

Field	What it does
`description`	Tells Claude when to use the skill. Always in context
`argument-hint`	Shown in autocomplete, so a developer typing `/map-dependencies` sees that a package name is expected
`$ARGUMENTS`	Replaced with whatever the developer typed after the command. `$0`, `$1` pick single arguments
`context: fork`	Runs the skill in a new subagent. The subagent does not see your conversation, and only its result comes back
`agent`	Which subagent type runs a forked skill: `Explore`, `Plan`, `general-purpose` (the default) or a custom agent from `.claude/agents/`
`allowed-tools`	Tools Claude may use without asking for permission during the turn that runs the skill
`disallowed-tools`	Tools removed from Claude's pool while the skill is active

A forked skill must contain a task. If SKILL.md holds only guidelines, such as "use these API conventions", the subagent has nothing to do and returns nothing useful. Keep reference conventions in a normal skill or in CLAUDE.md.

What allowed-tools does in current Claude Code

The exam guide describes allowed-tools as the way to restrict a skill's tools. In current Claude Code, it pre-approves the listed tools for the turn that invokes the skill. It does not remove other tools; your normal permission settings still govern them. To take tools away, list them in disallowed-tools, or fork the skill into an agent type with a limited tool set. The built-in Explore agent cannot use Write or Edit, so the example above cannot change files. When an exam option uses allowed-tools in frontmatter to limit what a skill does, it matches the guide's wording.

Command, skill or CLAUDE.md?

Situation	Choose	Why
A team checklist every developer should run as `/review`	Project skill or command under `.claude/`, committed	Shared through version control
Your own variant of a team skill	Personal skill in `~/.claude/skills/` with a different name	Stays on your machine and does not hide the team version
A standard that applies to every task, such as the build command	CLAUDE.md	Loaded every session
A workflow needed only sometimes, such as writing release notes	Skill	Loads only when invoked
A skill that reads many files and produces long output	Add `context: fork`	Only the summary returns to the main session
A workflow with side effects, such as a deploy	Add `disable-model-invocation: true`	Claude cannot start it on its own
A rule Claude must never skip, such as "never push to main"	PreToolUse hook or permission deny rule	CLAUDE.md and skills are instructions; a hook is code that runs every time
A custom subagent needs a team skill	List it in the subagent's `skills` field	Subagents do not inherit the parent session's skills
Several repositories need the same skills, hooks and subagents, kept in step	Package them as a plugin and share it through a marketplace	One versioned install; its skills run as `/plugin-name:skill-name`

Rules that decide exam answers

Shared means committed under .claude/. If every developer must get the command when they clone or pull, it goes in the project's .claude/commands/ or .claude/skills/, not in ~/.claude/ and not in CLAUDE.md.
Always needed goes in CLAUDE.md; sometimes needed goes in a skill. Putting a long occasional workflow in CLAUDE.md costs context in every session.
Verbose or exploratory output means context: fork. Codebase scans and brainstorming runs stay in the subagent, and the main session keeps its context for the real work.
Personal variants get their own name. A same-name personal skill overrides the team skill for that developer.
A forked skill needs a task, not just guidelines. The subagent starts without your conversation, so the instructions must stand alone.
A skill that never fires has a vague description. Fix the description, not CLAUDE.md, when Claude does not pick up a skill on its own.

Where it appears in the exam

Claude Code Configuration & Workflows is a primary domain in three of the six exam scenarios: Code Generation with Claude Code, Developer Productivity with Claude, and Claude Code for Continuous Integration. The Code Generation scenario names custom slash commands directly.

Two sample questions

These are original Timo practice questions. They are not official exam questions.

Question 1

A platform team keeps a /migrate-db skill in the repository. One developer wanted extra seeding steps for his local data, so he created ~/.claude/skills/migrate-db/SKILL.md. Last week the team added a safety check to the shared skill, but his sessions still run the old steps. What should he do?

A. Rename his personal skill to something like migrate-db-local so the team's /migrate-db runs for him again.B. Move his personal skill into the repository's .claude/skills/ folder under the same name.C. Add a line to his CLAUDE.md telling Claude to prefer the team's version of the skill.D. Add disable-model-invocation: true to his personal skill's frontmatter.

Answer: A. A personal skill with the same name takes precedence over the project skill, so his copy hides the team version. A different name gives him both. B replaces the team skill for everyone. C is an instruction that cannot change which file loads. D only stops Claude from starting the skill on its own; the name clash remains.

Question 2

A team's /audit-deps skill reads hundreds of files and prints long dependency listings into the session. After running it, developers find Claude loses track of earlier work in the same session. Which change fixes this while keeping the skill?

A. Move the skill's instructions into CLAUDE.md so they load once at the start of each session.B. Add allowed-tools: Read Grep so the skill has fewer tools to produce output with.C. Add context: fork to the skill's frontmatter so it runs in a subagent and returns only a summary.D. Add argument-hint: [directory] so developers are prompted to scan a smaller folder.

Answer: C. A forked skill runs in its own context, so the listings stay in the subagent and only the result reaches the main session. A loads the instructions into every session and still puts the output in the main conversation. B changes which tools are pre-approved, not how much output lands in context. D shows a hint; developers can still scan everything.

Build exercise

In a test repository, create .claude/skills/map-dependencies/SKILL.md from the example above. Commit it, clone the repository into a second folder, and confirm /map-dependencies appears with its argument hint.
Run the skill once without context: fork and once with it. Run /context after each run and compare how much of the context window was used.
Create ~/.claude/skills/map-dependencies/SKILL.md with different instructions. Confirm your personal version now runs instead of the team one. Rename it to map-dependencies-mine and confirm both appear.
Write a deploy skill with disable-model-invocation: true and ask Claude to "deploy this". Confirm Claude does not start the skill on its own and suggests you run /deploy.

Practise this topic

Claude Certified Architect practice exam: free, 20 questions, no sign-up
Claude Certified Architect hub
CCAR-F study guide: all topics
Same topic in another exam: Claude Code Operation (CCDV-F)
Previous topic: 3.1 CLAUDE.md hierarchy
Next topic: 3.3 Path-specific rules

Sources

Claude Certified Architect Foundations Exam Guide, version 1.0, effective July 2026 (Anthropic), task statement 3.2
Claude Code documentation: Extend Claude with skills
Claude Code documentation: Create custom subagents
Claude Code documentation: Explore the .claude directory
Claude Code documentation: Plugins overview