Domain 3 · Statement 3.2 2 of 6

Create and configure custom slash commands and skills

What you need to know

Project directory = shared through version control. Home directory = yours alone.
context: fork isolates a skill in a sub-agent context; only its result returns.
allowed-tools pre-approves the tools a skill needs so it runs without permission prompts; argument-hint prompts for missing parameters.
Load timing decides: every session → CLAUDE.md; only for this task → skill.
Personal variant of a team skill: same directory idea, different name, no effect on colleagues.

Slash commands and Agent Skills package a repeatable workflow so a developer can invoke it on demand instead of retyping a prompt. The exam tests where you put them, which decides who gets them, and how you configure them, which decides how they behave.

Scoping: who receives it

Location	Scope	Committed?
`.claude/commands/`	slash commands for the whole team	Yes — reviewed like any other file
`~/.claude/commands/`	your own slash commands, across all your projects	No
`.claude/skills/`	the team's skills	Yes
`~/.claude/skills/`	your personal variant — give it a different name	No

The different name is the point of the last row: it keeps the team's version working untouched while you run your own.³⁷

Skill frontmatter

A skill lives in a SKILL.md file whose YAML frontmatter configures how it runs. Three options are tested.

Option	What it does	Stem that points at it
`context: fork`	runs the skill in an isolated sub-agent context and returns only its result	a skill floods the conversation or exhausts context with discovery output
`allowed-tools`	pre-approves the listed tools for the turn that invokes the skill, so they run without a permission prompt	a skill keeps stopping to ask before tools it obviously needs
`argument-hint`	states the parameters expected, prompting for them when none are given	developers invoke the skill with no arguments

Those are the three the guide tests. Two neighbors are worth knowing because they change what you build rather than what you call it. agent picks which subagent type runs the fork, and background (default true) means the forked skill runs while you keep working and delivers its result later.³⁶ Set background: false if the invoking turn has to wait for it.

Do not confuse this "fork" with Domain 1's fork_session (1.7). context: fork isolates a skill's working context, so its file reads and intermediate notes never enter the main conversation — only its final result does. fork_session creates branches that inherit a shared analysis baseline.

Skills vs CLAUDE.md

This is the recurring judgment call, and it turns on load timing.

	`CLAUDE.md`	Skill
Loaded	always	on invocation
Holds	universal standards that must hold every session	task-specific workflows needed when that task comes up
Context cost	paid in every session	paid only when you call it

So a rarely used, verbose procedure sitting in CLAUDE.md is in the wrong place. Move it to a skill and it leaves every session's context while staying one command away.

Where to put it: CLAUDE.md, project command/skill, or personal command/skill

Help the learner choose the right home for an instruction on two axes — always needed versus invoked on demand, and team-wide versus personal — with each of the four cells naming the file location that fits.

context: fork — verbose skill output stays out of the main conversation

Show that a skill declared with context: fork executes in an isolated sub-agent context and returns only a summary, so the main session context is preserved.

Worked examples

A project-scoped /review-pr command every engineer gets from the repo

Scenario 2 · Code Generation with Claude Code

The team keeps rewriting the same pre-PR review prompt from memory, and everyone's version differs. Putting it in .claude/commands/review-pr.md makes it a committed, reviewable artifact: /review-pr behaves identically for everyone, and improving the prompt is a normal pull request. Had it gone in ~/.claude/commands/, only its author would have it — the same scoping trap as 3.1.

markdown

---
description: Review the current branch against our team review criteria
argument-hint: [base-branch]
---

Review the diff between $ARGUMENTS (default: main) and HEAD.

Check, in this order:
1. Error handling on every new external call.
2. Test coverage for new branches, using the fixtures in tests/fixtures/.
3. Public API changes — flag anything that needs a CHANGELOG entry.

Report findings grouped by severity. Do not comment on formatting;
the linter owns that.

.claude/commands/review-pr.md — committed, so the whole team has /review-pr

context: fork for a verbose codebase-analysis skill

Scenario 4 · Developer Productivity with Claude

An "audit dependencies" skill reads every package.json in a monorepo, greps for usages and produces pages of intermediate notes. Run inline, it fills the main conversation with noise and crowds out the actual task.

Declaring context: fork runs it in an isolated sub-agent context: the exploration happens there and only the summary comes back. The same reasoning applies to exploratory skills such as "brainstorm three alternative designs" — you want the conclusions, not the discarded branches. Listing allowed-tools lets the audit's read and write calls run without stopping for approval each time, and argument-hint makes the expected scope explicit.

Read allowed-tools as pre-approved, not only these. That is the exam's framing — the guide's phrase is "restrict tool access during skill execution" and that is the credited reading. It is also the safe one to carry into real work, where the field grants permission and leaves every other tool callable. The field that actually removes a tool is disallowed-tools.

markdown

---
name: dependency-audit
description: Audit dependency versions and unused packages across the monorepo
context: fork
allowed-tools: Read, Grep, Glob, Write
argument-hint: <package-path or "all">
---

Audit $ARGUMENTS.

1. Collect declared dependencies and their versions.
2. Grep for actual imports to find declared-but-unused packages.
3. Flag version drift between packages.

Return only a table of findings plus a one-paragraph summary.
Write the full detail to reports/dependency-audit.md.

.claude/skills/dependency-audit/SKILL.md

Choosing between a skill and CLAUDE.md

Two candidate rules for a team:

"Every exported function needs a TSDoc comment." This must hold in every session, for every change, so it belongs in CLAUDE.md (or a .claude/rules/ file) as an always-loaded standard.
"How to generate a new database migration: run the generator, hand-edit the down step, verify against the staging snapshot, update the fixture set." This is a 40-line procedure needed a few times a month. Keeping it in CLAUDE.md costs context in every unrelated session; as a skill it is loaded only when invoked.

If an engineer wants a stricter personal variant of the migration skill, they create it in ~/.claude/skills/ under a different name so the team's version keeps working unchanged for everyone else.

Anti-patterns

Storing a team workflow in ~/.claude/commands/ instead of .claude/commands/ because personal command directories are not version-controlled so teammates never receive the command.
Running a verbose analysis or brainstorming skill inline instead of with context: fork because its intermediate output consumes the main conversation context that the real task needs.
Reading allowed-tools as a sandbox instead of a pre-approval because the field grants permission and every unlisted tool stays callable — disallowed-tools is what removes one.
Pasting a long, rarely used procedure into CLAUDE.md instead of packaging it as an on-demand skill because always-loaded memory pays that context cost in every single session.

How it is examined

Any stem about a skill "flooding the conversation" or "exhausting context with discovery output" is pointing at context: fork, not at shortening the prompt or clearing history.
When the stem says an engineer wants a customized behavior "without affecting teammates", the answer is a personal variant in ~/.claude/skills/ with a different name — not editing the shared .claude/skills/ file.
For skill-vs-CLAUDE.md items, decide on load timing: "must apply to every change" points to CLAUDE.md, "needed only for this specific task" points to a skill. Distractors often propose putting the workflow in both.

Beyond the exam — what the API does that this does not grade

Read allowed-tools as a grant, not a fence. In Claude Code it "does not restrict which tools are available: every tool remains callable", and your permission settings still govern anything not listed.³⁶ The grant covers the turn that invokes the skill and clears with your next message.

Field	What it does
`allowed-tools`	pre-approves the listed tools, so they run without a permission prompt
`disallowed-tools`	removes the listed tools from Claude's pool while the skill is active

Two consequences you carry into real work. A project skill can grant itself broad tool access, which is why the docs tell you to review .claude/skills/ before trusting a repository. And a forked skill runs in the background by default, so the invoking turn does not receive its result — chain work after it only with background: false.³⁶

References — 2 sources

Extend Claude with skills Anthropic The frontmatter reference. `allowed-tools` grants pre-approval for the invoking turn and "does not restrict which tools are available: every tool remains callable" — the restricting field is `disallowed-tools`. It also documents the companions to `context: fork`: `agent` selects the subagent type, and `background` defaults to `true`, so the forked skill runs while you keep working.
Agent Skills in the SDK Anthropic How the same `.claude/skills/` and `~/.claude/skills/` files load when the surface is the Agent SDK rather than the CLI — the case Scenario 4 keeps putting the reader in.

All sources verified · Aug 21, 2026

Live product docs — where they differ from the exam guide, answer from the guide. All references

Exam guide, verbatim — what is measured

Knowledge of

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

Skills in

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)