What You Need to Know
Claude Code supports two mechanisms for extending its functionality: custom slash commands and skills. The exam tests your understanding of where each lives, how each is scoped, and which configuration options apply to skills.
Custom Slash Commands: Two Scoping Levels
Project-scoped: .claude/commands/
Commands stored in .claude/commands/ are version-controlled and shared via git. Every developer who clones or pulls the repository gets these commands automatically. Use this location for team-wide workflows: /review, /deploy-check, /lint, /migration-guide.
Create a Markdown file in this directory. The filename (minus the extension) becomes the command name. For example, .claude/commands/review.md creates the /review command.
<!-- .claude/commands/review.md --> 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
User-scoped: ~/.claude/commands/
Commands stored in ~/.claude/commands/ are personal. They are not version-controlled or shared. Use this for individual productivity workflows that other team members do not need: personal code formatting preferences, shortcuts for your specific development environment.
Key Concept
The scoping pattern is consistent across Claude Code: project-level (.claude/) is shared via git; user-level (~/.claude/) is personal. This applies to CLAUDE.md, commands, skills, and rules. Memorise this pattern — it appears throughout Domain 3.
Skills: On-Demand Workflows with Configuration
Skills live in .claude/skills/ with SKILL.md files. They support frontmatter configuration that commands do not have. Skills are task-specific workflows invoked on demand — they are not loaded automatically like CLAUDE.md.
The three critical frontmatter options:
context: fork
Runs the skill in an isolated sub-agent context. All verbose output stays contained in the fork. The main conversation remains clean and uncluttered. This is essential for:
- Codebase analysis (produces extensive file listings and code excerpts)
- Brainstorming (generates many alternatives and evaluations)
- Any task that produces noisy, exploratory output
Without context: fork, skill output flows into the main conversation and consumes context window tokens. For verbose skills, this degrades the quality of subsequent responses.
--- context: fork allowed-tools: - Read - Grep - Glob argument-hint: "Provide a feature description or area of the codebase to analyse" ---
allowed-tools
Restricts which tools the skill can use during execution. This is a security boundary. A read-only analysis skill should not have access to Write or Bash. A documentation generation skill should not be able to modify source code.
--- allowed-tools: - Read - Grep - Glob ---
argument-hint
Prompts the developer for required parameters when the skill is invoked without arguments. Improves the developer experience by making inputs explicit rather than relying on the developer to remember what the skill needs.
--- argument-hint: "Specify the module path to analyse (e.g., src/api/auth)" ---
Skills vs CLAUDE.md: The Critical Distinction
This distinction is tested directly on the exam:
- Skills = on-demand, task-specific workflows. Invoked when needed. Not loaded automatically.
- CLAUDE.md = always-loaded, universal standards. Applied automatically to every session.
The rule: do not put task-specific procedures in CLAUDE.md. Do not put universal standards in skills.
API naming conventions that must apply to every code generation task belong in CLAUDE.md (or .claude/rules/). A codebase analysis workflow that a developer runs occasionally belongs in a skill.
Personal Skill Customisation
Create personal variants in ~/.claude/skills/ with different names to avoid affecting teammates. If the team has a standard /analyse skill but you prefer a more verbose version, create your own in ~/.claude/skills/ with a different name (e.g., /deep-analyse). Your personal skill does not override or conflict with the team version.
Where Commands vs Skills Go: Quick Reference
| Need | Location | Scoping |
|---|---|---|
| Team-wide slash command | .claude/commands/ | Project (shared via git) |
| Personal slash command | ~/.claude/commands/ | User (not shared) |
| Team-wide skill with config | .claude/skills/ | Project (shared via git) |
| Personal skill variant | ~/.claude/skills/ | User (not shared) |
| Universal standards | .claude/CLAUDE.md or root CLAUDE.md | Project (always loaded) |
| Personal preferences | ~/.claude/CLAUDE.md | User (not shared) |
Exam Traps
Placing a team-shared command in ~/.claude/commands/ (user-scoped) instead of .claude/commands/ (project-scoped)
~/.claude/commands/ is personal and not version-controlled. Team commands that should be available to everyone on clone must go in .claude/commands/ inside the repository.
Thinking skills load automatically like CLAUDE.md
Skills are on-demand. They must be explicitly invoked by the developer. CLAUDE.md loads automatically for every session. If the exam asks about 'automatic application of conventions,' the answer is CLAUDE.md or .claude/rules/, not skills.
Not knowing when to use context: fork
context: fork isolates verbose skill output from the main conversation. Without it, brainstorming or codebase analysis output pollutes the context window. The exam will present scenarios where verbose output clutters the main conversation — the fix is context: fork.
Putting task-specific workflows in CLAUDE.md
CLAUDE.md is for always-loaded universal standards. Task-specific procedures (code review workflows, analysis routines, brainstorming templates) belong in skills that are invoked on demand.
Practice Scenario
A team wants a /review command available to everyone who clones the repository. A developer also wants a personal /brainstorm skill that produces verbose codebase analysis output without cluttering the main conversation. Where should each be created and what configuration does the skill need?
Build Exercise
Create Custom Commands and Skills
What you'll learn
- Distinguish between project-scoped and user-scoped command locations
- Configure SKILL.md frontmatter with context: fork, allowed-tools, and argument-hint
- Understand when to use skills vs CLAUDE.md for conventions vs workflows
- Verify scoping boundaries between shared and personal configuration
- Apply the context: fork pattern to isolate verbose output from the main conversation
- 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 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.
- Add allowed-tools to the brainstorm skill, restricting it to Read, Grep, and Glob (read-only operations)
Why: The allowed-tools frontmatter restricts which tools a skill can access, creating a security boundary. A read-only analysis skill should never have Write or Bash access. The exam tests this as a security best practice.
You should see: The SKILL.md frontmatter now includes an allowed-tools list with exactly Read, Grep, and Glob. The skill cannot use Write, Bash, or other tools during execution.
- 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.
- 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.
- 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.