What you will be able to do
- Place a skill or command in the project or personal location depending on who should get it
- Explain how .claude/commands/ files relate to skills in .claude/skills/
- Predict which skill runs when the same name exists in personal and project locations, and name a personal variant so it doesn't shadow the team's version
- Decide whether guidance belongs in CLAUDE.md or in an on-demand skill
Key concept
Skill location decides who gets it — A skill is a SKILL.md file in a named folder, and the folder it sits in decides its audience. Put it in the repository's .claude/skills/ and commit it to share it with the team. Put it in ~/.claude/skills/ to keep it for yourself across all your projects.
1.Two folders, two audiences
A Claude Code skill is a directory with a SKILL.md file inside it. You invoke it by name as /name, or Claude can pick it up on its own when your request matches it. The directory's location matters more than anything in the file, because it decides who can use the skill. For this exam, two locations count: the project location inside the repository and the personal location in your home directory.
| Location | Path | Loads in |
|---|---|---|
| Personal | ~/.claude/skills/<skill-name>/SKILL.md | All your projects on this machine, but not Cowork or cloud sessions |
| Project | .claude/skills/<skill-name>/SKILL.md | Sessions in this repository. Commit it so your team gets it too |
The project location is how a team standardises a workflow. The skill lives in the repo, goes through code review like any other file, and every teammate who clones the repo gets it. The personal location is for your own habits. Nothing under ~/.claude/ is committed, so a personal skill follows you from project to project on your machine and never reaches anyone else. Note the limit in the table: personal skills don't load in Cowork or cloud sessions.
Sources1
2.Custom slash commands in .claude/commands/
Before skills, the way to add a custom slash command was a single Markdown file in a commands/ folder. Project commands go in .claude/commands/ and are committed for the team. Personal commands go in ~/.claude/commands/. The documentation still describes both locations, and it treats commands as the older form of the same feature, not a separate system.
| Aspect | commands/*.md | skills/<name>/SKILL.md |
|---|---|---|
| What it is | Single-file prompts; same mechanism as skills | Reusable prompts invoked with /name or auto-invoked |
| Scope | Project and global | Project and global |
| Frontmatter | The skill fields except name and paths | Full skill frontmatter |
So a team command in .claude/commands/ keeps working and is shared through version control just like a project skill. The documentation recommends skills for anything new, because a skill is a folder and can hold supporting files next to SKILL.md, while a command is one file. If a skill and a command file have the same name, the skill runs.
3.Same name in two places, and personal variants
The personal one runs. Among enterprise, personal and project locations, the documented order is enterprise first, then personal, then project. A personal skill with the same name as the team's skill therefore shadows the team version for you. Your teammates aren't affected, since your home directory isn't committed. But you now run a different /deploy from everyone else without seeing any sign of it, and when the team updates the project skill, you won't get the change.
That is why personal variants get their own names. Save your version under a different name, for example ~/.claude/skills/deploy-verbose/. Then /deploy still runs the shared version, your variant is available as /deploy-verbose, and nobody's behaviour changes by accident, including yours. Bundled skills follow a related rule: a skill of yours replaces a bundled command of the same name but not its aliases. A project code-review skill replaces /code-review, and the bundled alias /review never runs it.
The skill. When a skill and a file in .claude/commands/ share a name, the skill wins.
Sources1
4.Skills or CLAUDE.md?
CLAUDE.md and skills both give Claude instructions, but they load at different times. CLAUDE.md content is loaded into every session. The memory documentation suggests it for coding standards, workflows and project architecture: rules that apply whatever task is in progress. A skill loads in stages, so most of it stays out of context until it's needed.
| Level | When loaded | Token cost | Content |
|---|---|---|---|
| Level 1: Metadata | Always (at startup) | ~100 tokens per Skill | name and description from YAML frontmatter |
| Level 2: Instructions | When Skill is triggered | Under 5k tokens | SKILL.md body with instructions and guidance |
| Level 3+: Resources | As needed | None until accessed | Bundled files. Reference files load into context when read. Scripts run through bash, and only their output enters context |
That gives a working rule. Put a universal standard that should shape every edit (indentation, where handlers live, which test command to run) in CLAUDE.md. Put a task-specific workflow that matters only when you do that task (cutting a release, summarising a diff, running a migration checklist) in a skill. Otherwise every session pays for a procedure it seldom uses. Only the name and description stay loaded between uses, so a team can keep many skills installed without filling the context window.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Custom commands in .claude/commands/ were replaced by skills and no longer load, so a team must migrate them before they work.Why is that wrong?
Command files are the older format and still work. They support the same frontmatter as skills except name and paths. Skills are only recommended for new work.
Covered in Custom slash commands in .claude/commands/
2.A committed project skill always beats a personal skill of the same name, so reusing the team's skill name for your personal variant is harmless.Why is that wrong?
Personal beats project. A same-named personal skill silently replaces the team version in your sessions, which is why personal variants should get different names.
3.An installed skill costs as much context as CLAUDE.md, because its full instructions are loaded at the start of every session.Why is that wrong?
At startup only the name and description are loaded. The SKILL.md body enters context when the skill is triggered, and bundled files load only when they are accessed.
Covered in Skills or CLAUDE.md?
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.https://code.claude.com/docs/en/skillsOfficial docs
“All your projects on this machine, but not Cowork or cloud sessions”
↩︎ Two folders, two audiences“Commit it so your team gets it too”
↩︎ Two folders, two audiences“Prefer a skill for new work, since skills also support supporting files.”
↩︎ Custom slash commands in .claude/commands/“Enterprise over personal, and personal over project.”
↩︎ Same name in two places, and personal variants“Your skill replaces the bundled command, but not its aliases.”
↩︎ Same name in two places, and personal variants“Commit it so your team gets it too”
↩︎ Key concept“a Markdown file in .claude/commands/ is the older format and still works.”
↩︎ Exam trap 1“With deploy in both ~/.claude/skills/ and the project’s .claude/skills/, /deploy runs the personal one”
↩︎ Exam trap 2 - 2.https://code.claude.com/docs/en/claude-directoryOfficial docs
“Single-file prompts; same mechanism as skills”
↩︎ Custom slash commands in .claude/commands/“Instructions loaded every session”
↩︎ Skills or CLAUDE.md? - 3.https://code.claude.com/docs/en/memoryOfficial docs
“Coding standards, workflows, project architecture”
↩︎ Skills or CLAUDE.md? - 4.
“Skills load on demand, so you don't have to repeat the same guidance across conversations.”
↩︎ Skills or CLAUDE.md?“until a Skill is triggered, only its name and description occupy context.”
↩︎ Exam trap 3