Commands and skills: where they go and how to configure them

CLAUDE.md always loads. But many things are only needed sometimes: a review checklist, a release workflow, a codebase analysis. That’s what commands and skills are for: they’re used on demand.

Project or personal

	Team (in the repo)	Personal
Slash command	.claude/commands/	~/.claude/commands/
Skill	.claude/skills/<name>/SKILL.md	~/.claude/skills/<name>/SKILL.md

A /review that everyone who clones the repo must have goes in .claude/commands/review.md: it’s versioned and arrives with every pull. If you created it in ~/.claude/commands/, the push succeeds but the file was never committed, because it’s outside the repo. In a command, the file name defines the command and $ARGUMENTS receives whatever is typed after it (for example, the PR number).

A skill is a task workflow with its own folder. It’s invoked with /name, or the model loads it when its description matches the task. At session start only the name and description load; the full content enters when it’s used. In recent versions of Claude Code, commands and skills create the same /name, and skills add frontmatter and supporting files.

The frontmatter the exam asks about

---
name: analyze-module
description: Analyzes a module's dependencies and technical debt
context: fork
allowed-tools: Read, Grep, Glob
argument-hint: "[module-path]"
---

• context: fork: the skill runs in an isolated subagent and only the final summary returns to the main conversation. Use it when a skill produces verbose output (listings, dependency graphs) or exploration (brainstorming) that would flood the session.
• allowed-tools: which tools the skill can use without asking for permission. In the exam it appears as the way to scope tools while the skill runs, for example to prevent destructive actions. It defines which tools it uses, not how much it prints.
• argument-hint: shows which argument the skill expects when someone invokes it without one.

Fields like output-limit or max-tokens don’t exist, and paths belongs to rules in .claude/rules/.

Personal variants

If you want a more detailed version of the team’s /analyze, create it in ~/.claude/skills/ under a different name (deep-analyze). With the same name, the personal one shadows the team’s in your sessions and it gets confusing which one runs. Changing the repo’s version affects everyone.

Skill or CLAUDE.md

Always loaded	On demand
CLAUDE.md and .claude/rules/ without paths	Skills and commands
Conventions that apply to every task	Workflows for a specific task

A naming convention that must guide every generation never goes in a skill: it depends on someone invoking it. A long, occasional checklist does.

The usual traps

• Defining commands inside CLAUDE.md or in a made-up config.json.
• Using allowed-tools to reduce a skill’s output: that’s context: fork.
• Copying personal commands by hand onto every machine instead of committing them.
• Thinking /memory loads commands.

In the exam

“Available to everyone who clones” is .claude/; “just for me” is ~/.claude/. Output that clutters the conversation: context: fork. A universal convention: CLAUDE.md, never a skill.