Lesson 6 · Domain 3 — Claude Code Configuration & Workflows (20% of exam)

Slash Commands vs. Skills

CLAUDE.md is always loaded, for every file, every session. Commands and skills are the opposite: on-demand, invoked when you actually need them. This lesson is about picking the right one, and configuring it so it behaves the way you expect.

Slash commands: shared vs. personal, by directory

Same personal/shared split as CLAUDE.md, and for the same reason:

.claude/commands/ — project-scoped, version-controlled, available to every developer the moment they clone or pull.
~/.claude/commands/ — user-scoped, personal, invisible to teammates.

If you want a /review command running your team's checklist for everyone automatically, it belongs in .claude/commands/ in the repo — not in your home directory, and not described in CLAUDE.md (CLAUDE.md holds context and instructions, not command definitions).

Skills: on-demand workflows with real configuration

A skill lives in .claude/skills/ as a SKILL.md file with frontmatter that actually changes its runtime behavior:

---
name: audit-deps
description: Audit dependencies for known vulnerabilities and outdated majors
context: fork
allowed-tools: Read, Grep, Bash
argument-hint: "[package-name]"
---

context: fork — runs the skill in an isolated sub-agent context. Its (often verbose) output — codebase analysis, brainstormed alternatives — never pollutes the main conversation. Only the result comes back.
allowed-tools — restricts what the skill can touch while it runs. Scope a skill to read-only tools, for instance, if it should never be able to take a destructive action.
argument-hint — prompts the developer for required parameters if they invoke the skill without supplying them.

Personal variants work the same way as commands: create your own copy under a different name in ~/.claude/skills/ without touching the shared team version.

Choosing between the two

Skills are for on-demand, task-specific workflows you invoke when needed. CLAUDE.md is for standards that should apply to every session automatically, with no invocation required. If you find yourself writing "when doing X, do Y" inside CLAUDE.md, and X is something that happens occasionally rather than constantly, that's usually a skill trying to escape.

Grounded in the official guide's own sample question

Sample Question 4 in the exam guide asks exactly this: a team wants a /review command with their checklist, available to every developer on clone. The correct answer is .claude/commands/ in the repo — not personal ~/.claude/commands/, not CLAUDE.md, and not a fabricated .claude/config.json commands array (which doesn't exist in Claude Code). Watch for exactly this shape of distractor: a plausible-sounding config mechanism that simply isn't real.

Why this matters beyond the exam

Primary source: Anthropic's Extend Claude Code docs cover both custom commands and Agent Skills with full frontmatter reference — this lesson compresses Task Statement 3.2.

Check your understanding

Q1. You want a /review slash command with your team's checklist, available to every developer the moment they clone the repo. Where do you put it?

Q2. A skill produces very verbose codebase-analysis output you don't want cluttering the main conversation. Which frontmatter option isolates it?

Q3. When should something live in a skill rather than CLAUDE.md?

Want to sketch a skill's frontmatter for a workflow you actually use? Tell me what it should do and I'll help you configure it.

← Lesson 5: CLAUDE.md Hierarchy Study Plan Lesson 7: Plan Mode & CI/CD →