Custom Slash Commands and Skills

Official Exam Guide Objectives

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)

What You Need to Know

Custom commands and skills are now one system rather than two: the Skills system. Both .claude/skills/ and .claude/commands/ yield /commands that behave identically, but what you put in each differs. Under .claude/skills/ the unit is a directory holding a SKILL.md — .claude/skills/deploy/SKILL.md. Under .claude/commands/ it is a single Markdown file, .claude/commands/deploy.md. Dropping a loose .md straight into .claude/skills/ produces nothing. Treat .claude/skills/ as the canonical location; .claude/commands/ remains supported for backward compatibility.

The Unified Skills System

Either path gets you the same thing — a /command a developer can type:

• .claude/commands/deploy.md creates /deploy — a flat file whose filename becomes the command name
• .claude/skills/deploy/SKILL.md also creates /deploy — one directory per skill, named after the command, with SKILL.md as the required entrypoint inside it

What tips the recommendation towards the skills path is what it adds on top: room for supporting files next to the SKILL.md, automatic discovery so Claude can reach for a skill when the request matches it, and a defined outcome when both paths define the same name — the skill takes it. Frontmatter is identical across the two (context: fork, allowed-tools, argument-hint) and the resulting /command is identical, so nothing already sitting in .claude/commands/ needs touching.

Two Scoping Levels

Project-scoped (shared via git):

.claude/skills/ (canonical) or .claude/commands/ (alias), inside the repository. Both are committed, so anyone who clones or pulls has the commands immediately. This is where team workflows belong: /review, /deploy-check, /lint, /migration-guide.

<!-- .claude/commands/review.md — creates /review -->
Work through the staged diff and report against these, in order:
1. Are failures handled the way the rest of the codebase handles them?
2. Does every new exported function have a test that would catch a regression?
3. Do new endpoints match the naming already in use?
4. Is there anything credential-shaped committed by accident?

User-scoped (personal):

~/.claude/skills/ (canonical) or ~/.claude/commands/ (alias). Nothing here is committed or shared, which makes it the right home for workflows that suit how you work and would only be noise for everyone else.

Skills Frontmatter: Optional Configuration

A SKILL.md under .claude/skills/ may carry YAML frontmatter to configure how it runs. The same frontmatter is honoured for .claude/commands/ files, though .claude/skills/ is where configured skills are meant to live. Note that skills are invoked for a task rather than loaded continuously — they are not CLAUDE.md.

The three critical frontmatter options:

context: fork

Runs the skill inside an isolated sub-agent context, so whatever it generates stays there and the main conversation is untouched. That matters for anything noisy:

• Codebase analysis (produces extensive file listings and code excerpts)
• Brainstorming (generates many alternatives and evaluations)
• Any task that produces noisy, exploratory output

Leave it out and every line the skill produces lands in the main conversation, spending context that later turns will need — which is why a verbose skill without context: fork degrades the responses that follow it rather than just the one it ran in.

Frontmatter goes at the very top of the SKILL.md. Invoking it as /analyse-feature means the file to edit is .claude/skills/analyse-feature/SKILL.md:

---
context: fork
allowed-tools:
  - Read
  - Grep
  - Glob
---

allowed-tools

Pre-approves what it lists, so the skill can use those tools without stopping for a permission prompt. Read carefully what it does not do: it is not a restriction. Every other tool remains reachable, governed by your usual permission settings exactly as before. It buys uninterrupted execution for a workflow you trust, not a sandbox.

---
allowed-tools:
  - Read
  - Grep
  - Glob
---

Taking tools away — the actual security boundary — is disallowed-tools, or deny rules in your permission settings.

argument-hint

Tells the developer what the skill expects when they invoke it with nothing. It converts "I can never remember what this one wants" into a prompt at the point of use.

---
argument-hint: "Which module? Give a path, e.g. src/billing/invoices"
---

Skills vs CLAUDE.md: The Critical Distinction

This distinction is tested directly on the exam:

• Skills = invoked for a task. Their descriptions sit in context permanently so Claude knows what exists, while the body arrives only on invocation. That invocation may be explicit (/skill-name) or automatic — Claude reaches for a skill whose description fits the request, or one whose paths frontmatter matches the files being edited. Setting disable-model-invocation: true restricts a skill to explicit invocation only.
• CLAUDE.md = present from the start of every session, with nothing to invoke and no matching step.

Which gives the rule: procedures for a particular task do not belong in CLAUDE.md, and standing reference material does not belong in a skill.

Naming conventions that must shape every piece of generated code are always-on, so CLAUDE.md or .claude/rules/ is their home. A multi-step analysis somebody runs now and then is a skill. And conventions attaching to one file type — tests being the obvious case — fit path-scoped .claude/rules/ best, since those load as standing context whenever a matching file is in play.

Personal Skill Customisation

Personal variants live in ~/.claude/skills/ (or ~/.claude/commands/) under a name of their own. Where the team ships /analyse and you want something more thorough, build yours as /deep-analyse rather than redefining theirs — a distinct name keeps both available and leaves your colleagues' behaviour unchanged.

Where to Place Custom Commands: Quick Reference

Deep Dive

$ARGUMENTS and positional arguments

$ARGUMENTS expands to all arguments passed at invocation. If $ARGUMENTS doesn't appear anywhere in the skill or command body, Claude Code appends the arguments automatically as ARGUMENTS: <value> so they're never silently dropped. For positional access, $N is shorthand for $ARGUMENTS[N] with 0-based indexing — $0 is the first argument, $1 the second, and so on.

---
argument-hint: "[issue-number] [priority]"
---
Investigate issue #$0 (priority: $1) and propose a fix.

Invoking /triage 4521 high binds $0 to 4521 and $1 to high.

Sourcecode.claude.com › skillsfetched 2026-07-30

Full SKILL.md frontmatter field table

All frontmatter fields are optional; only description is recommended, since it's what Claude uses to decide when to auto-invoke the skill (falling back to the first paragraph of the body if omitted). The fields that matter for the exam:

Sourcecode.claude.com › skillsfetched 2026-07-30

context: fork and the agent field

context: fork runs the skill in a forked subagent context: the skill content becomes the prompt that drives the subagent, and that subagent has no access to the parent conversation's history. The agent field then selects which subagent configuration executes the forked skill — a built-in agent (Explore, Plan, general-purpose) or any custom subagent defined in .claude/agents/ — defaulting to general-purpose when omitted.

Sourcecode.claude.com › skillsfetched 2026-07-30

Dynamic context injection with the ! prefix

The !`<command>` syntax runs a shell command before the skill content is sent to Claude, and the command's output replaces the placeholder in the prompt — so Claude receives actual data (a git diff, a file listing) rather than the command text itself.

Review the staged changes:
!`git diff --staged`

Sourcecode.claude.com › skillsfetched 2026-07-30

Skill permission rules

Skill invocation itself can be gated with permission rules: Skill(name) matches an exact skill, Skill(name *) is a prefix match covering any arguments.

Sourcecode.claude.com › skillsfetched 2026-07-30

MCP prompts as slash commands

Separately from .claude/skills/ and .claude/commands/, MCP servers can expose their own prompts as slash commands in the form /mcp__servername__promptname, discovered dynamically from connected servers with server and prompt names normalised (spaces become underscores). Many prompts accept arguments, passed space-separated after the command, e.g. /mcp__github__pr_review 456.

Sourcecode.claude.com › mcpfetched 2026-07-30

Quick Reference

Exam Traps

Practice Scenario

Build Exercise

Create Custom Commands and Skills

Difficulty: Intermediate (2/4)

30 minutes

1. Create a project-scoped /review command in .claude/commands/review.md containing a team code review checklist

Why: Project-scoped commands are shared via git so every developer gets them on clone. The exam tests whether you place team commands in .claude/commands/ (project) vs ~/.claude/commands/ (personal).

You should see: A file at .claude/commands/review.md in the repository. Running /review in Claude Code triggers the code review checklist. The command appears when any developer clones the repository.

2. Create a personal /brainstorm skill in ~/.claude/skills/brainstorm/SKILL.md with context: fork in the frontmatter

Why: The context: fork frontmatter option isolates verbose skill output from the main conversation. Without it, codebase analysis output fills the context window and degrades subsequent responses. The exam directly tests this concept.

You should see: A SKILL.md file at ~/.claude/skills/brainstorm/SKILL.md with YAML frontmatter containing context: fork. The skill is available only in your sessions, not shared with teammates.

3. Add allowed-tools to the brainstorm skill, restricting it to Read, Grep, and Glob (read-only operations)

Why: The exam guide describes allowed-tools as restricting which tools a skill can access, and that is the expected exam answer. In current Claude Code it pre-approves the listed tools so they run without a permission prompt (disallowed-tools is the actual boundary), but the intent is the same: a read-only analysis skill should never be using Write or Bash.

You should see: The SKILL.md frontmatter now includes an allowed-tools list with exactly Read, Grep, and Glob. Under the exam-guide model the skill cannot use Write or Bash; in current Claude Code the list pre-approves those three tools for promptless use.

4. Add argument-hint to the brainstorm skill: "Provide a feature description or codebase area to explore"

Why: The argument-hint prompts developers for required parameters when invoking the skill without arguments. This improves developer experience and is one of the three SKILL.md frontmatter options tested on the exam.

You should see: The SKILL.md frontmatter now includes argument-hint. When a developer invokes /brainstorm without arguments, they see a prompt asking for a feature description or codebase area.

5. Test that /review appears for all project users (shared via git) and /brainstorm only for you

Why: This verifies the scoping boundary that the exam repeatedly tests: .claude/ is project-scoped and shared via git, while ~/.claude/ is user-scoped and personal. Confirming this experimentally solidifies the concept.

You should see: Running /review works in any clone of the repository. Running /brainstorm works only in your session. A colleague or fresh clone without your home directory config does not see /brainstorm as an available command.

6. Invoke the brainstorm skill and verify that its verbose output does not appear in the main conversation context

Why: The context: fork option runs the skill in an isolated sub-agent. The main conversation receives only the summary, not the full verbose output. This is critical for preserving context window tokens during exploratory tasks.

You should see: After invoking /brainstorm with a codebase area, the main conversation shows a concise summary of findings. The verbose file listings, code excerpts, and analysis notes are not visible in the main conversation history. Subsequent responses remain high quality because the context window is not filled with exploration output.

Sources

• Claude Code Skills Documentation (custom slash commands are part of the unified Skills system) — Anthropic
• Claude Code MCP Documentation (MCP prompts as slash commands) — Anthropic
• Claude Certified Architect Foundations Exam Guide — Task Statement 3.2 — Anthropic

Appendix A — Build Exercise Step Hints

Progressive hints revealed by the "Stuck? Get a nudge" control on each step.

Step 1. Create a project-scoped /review command in .claude/commands/review.md containing a team code review checklist

Why: Project-scoped commands are shared via git so every developer gets them on clone. The exam tests whether you place team commands in .claude/commands/ (project) vs ~/.claude/commands/ (personal).

You should see: A file at .claude/commands/review.md in the repository. Running /review in Claude Code triggers the code review checklist. The command appears when any developer clones the repository.

Create .claude/commands/review.md with content like:
Review the staged changes against our team checklist:
1. Check error handling patterns
2. Verify test coverage for new functions
3. Confirm API naming conventions
4. Flag any hardcoded credentials or secrets

Step 2. Create a personal /brainstorm skill in ~/.claude/skills/brainstorm/SKILL.md with context: fork in the frontmatter

Why: The context: fork frontmatter option isolates verbose skill output from the main conversation. Without it, codebase analysis output fills the context window and degrades subsequent responses. The exam directly tests this concept.

You should see: A SKILL.md file at ~/.claude/skills/brainstorm/SKILL.md with YAML frontmatter containing context: fork. The skill is available only in your sessions, not shared with teammates.

Create ~/.claude/skills/brainstorm/SKILL.md:
---
context: fork
---
Analyse the specified area of the codebase:
1. Map the module structure and dependencies
2. Identify patterns and anti-patterns
3. Suggest improvements with rationale

Step 3. Add allowed-tools to the brainstorm skill, restricting it to Read, Grep, and Glob (read-only operations)

Why: The exam guide describes allowed-tools as restricting which tools a skill can access, and that is the expected exam answer. In current Claude Code it pre-approves the listed tools so they run without a permission prompt (disallowed-tools is the actual boundary), but the intent is the same: a read-only analysis skill should never be using Write or Bash.

You should see: The SKILL.md frontmatter now includes an allowed-tools list with exactly Read, Grep, and Glob. Under the exam-guide model the skill cannot use Write or Bash; in current Claude Code the list pre-approves those three tools for promptless use.

Update the frontmatter to:
---
context: fork
allowed-tools:
  - Read
  - Grep
  - Glob
---

Step 4. Add argument-hint to the brainstorm skill: "Provide a feature description or codebase area to explore"

Why: The argument-hint prompts developers for required parameters when invoking the skill without arguments. This improves developer experience and is one of the three SKILL.md frontmatter options tested on the exam.

You should see: The SKILL.md frontmatter now includes argument-hint. When a developer invokes /brainstorm without arguments, they see a prompt asking for a feature description or codebase area.

Update the frontmatter to:
---
context: fork
allowed-tools:
  - Read
  - Grep
  - Glob
argument-hint: "Provide a feature description or codebase area to explore"
---

Step 5. Test that /review appears for all project users (shared via git) and /brainstorm only for you

Why: This verifies the scoping boundary that the exam repeatedly tests: .claude/ is project-scoped and shared via git, while ~/.claude/ is user-scoped and personal. Confirming this experimentally solidifies the concept.

You should see: Running /review works in any clone of the repository. Running /brainstorm works only in your session. A colleague or fresh clone without your home directory config does not see /brainstorm as an available command.

Run these checks:
1. git status — .claude/commands/review.md should be tracked
2. git ls-files ~/.claude/ — should return nothing (not in repo)
3. Ask a teammate to run /review (works) and /brainstorm (not found)

Step 6. Invoke the brainstorm skill and verify that its verbose output does not appear in the main conversation context

Why: The context: fork option runs the skill in an isolated sub-agent. The main conversation receives only the summary, not the full verbose output. This is critical for preserving context window tokens during exploratory tasks.

You should see: After invoking /brainstorm with a codebase area, the main conversation shows a concise summary of findings. The verbose file listings, code excerpts, and analysis notes are not visible in the main conversation history. Subsequent responses remain high quality because the context window is not filled with exploration output.

Invoke: /brainstorm src/api
Then scroll through your main conversation. You should see a concise summary like:
- Module structure: 5 files, 3 handlers
- Key pattern: factory-based dependency injection
- Suggested improvement: extract validation middleware
Not the full verbose exploration output.

Appendix B — Interactive Study Prompts

Two prompts to paste into Claude. B1 drills the judgement the exam actually measures; B3 reviews the configuration you wrote for the Build Exercise above. The exam simulator between them is the interactive quiz on this page.

B1. Concept Check — Discrimination Drill

B2. Exam Simulator

B3. Build Coach — Config Review

The Build Exercise and its hint ladder are already on this page. This prompt is for the one thing the page cannot do: review the configuration you actually wrote.