Personal vs Project Skills: Where Claude Code Skills Live

Claude Code loads personal skills from ~/.claude/skills/, which apply in every project on your machine, and project skills from .claude/skills/ in the repository, which apply to anyone working in that repo. It also loads skills from nested .claude/skills/ directories when you work in a subdirectory, from directories passed with --add-dir, from installed plugins, and from enterprise managed settings. When two skills share a name, enterprise beats personal, and personal beats project.

Use personal skills for your own habits and tools. Use project skills for anything tied to a codebase that teammates should get automatically.

Where can Claude Code skills live?

Location	Path	Scope	Shared via
Enterprise	Managed by your organization	Everyone in the org	Admin-managed settings
Personal	~/.claude/skills/<name>/SKILL.md	All your projects	Nothing; local to you
Project	.claude/skills/<name>/SKILL.md	One repository	Git
Nested	<subdir>/.claude/skills/<name>/SKILL.md	When working in that subdirectory	Git
Additional directory	<dir>/.claude/skills/ for each --add-dir <dir>	The current session	However you share that directory
Plugin	<plugin>/skills/<name>/SKILL.md	Wherever the plugin is installed	Marketplace

Each skill is a folder whose name matches the name field in its SKILL.md. The location changes only who sees the skill and which copy wins in a name collision.

How does skill precedence work?

When the same skill name exists in more than one place, Claude Code uses one:

1. Enterprise wins over everything.
2. Personal wins over project.
3. Project is used only if no higher-priority skill has the same name.

Two more rules:

• A skill wins over a same-named custom command in .claude/commands/. Both create /name, and the skill takes priority.
• Plugin skills never collide. They are namespaced as /<plugin>:<skill>, so a plugin’s review skill is /acme:review and coexists with your own review.

Personal winning over project is deliberate: you can override a team skill with your own variant on your machine. The cost is confusion. If your teammates report that /code-review behaves one way and you see another, check for a stale personal copy:

ls -d ~/.claude/skills/*/ | xargs -n1 basename | sort > /tmp/personal.txt
ls -d .claude/skills/*/  | xargs -n1 basename | sort > /tmp/project.txt
comm -12 /tmp/personal.txt /tmp/project.txt   # names defined in both

When should you use a personal skill?

Personal skills follow you, not the code. Good candidates:

• Your working style: how you like commits written, how terse you want explanations, your debugging routine. commit-craft and systematic-debugging are typical personal installs.
• Language and tool knowledge you use across repos: your preferred testing approach, a Postgres tuning playbook.
• Skills you are still developing. Iterate in ~/.claude/skills until a skill is stable, then promote it to a project.
• Anything that encodes your private setup, such as paths on your machine or your personal scripts.

Install a personal skill from this site:

curl -fsSL https://claudeskills.page/install.sh | sh -s -- systematic-debugging

When should you use a project skill?

Project skills follow the code. Good candidates:

• Repository procedures: the release checklist, the migration review rules, how to add an API endpoint.
• Conventions a reviewer would enforce: error-handling patterns, naming, the component structure in react-patterns.
• Onboarding knowledge: anything a new teammate would otherwise learn by asking.
• Skills that call repo scripts, since the scripts and the skill change together.

Install into the current repo and commit:

curl -fsSL https://claudeskills.page/install.sh | sh -s -- schema-migrations --project
git add .claude/skills/schema-migrations && git commit -m "Add schema-migrations skill"

Quick decision table

If the skill…	Put it in
Encodes your personal preferences	Personal
Is useful across many unrelated repos you work on	Personal
References files, scripts, or conventions in one repo	Project
Should be available to every contributor automatically	Project
Applies to only one package of a monorepo	Nested, in that package
Is shared by several repos owned by one team	--add-dir or a plugin
Must be enforced across the organization	Enterprise
Is still experimental	Personal, until stable

How do nested skills work in a monorepo?

In a monorepo, different packages often need different procedures. Put skills next to the code they serve:

repo/
├── .claude/skills/
│   └── release-checklist/        # whole repo
├── services/billing/
│   └── .claude/skills/
│       └── stripe-webhooks/      # loads when working in services/billing
└── apps/web/
    └── .claude/skills/
        └── component-patterns/   # loads when working in apps/web

Nested skills load when you work in that subdirectory, so the billing team’s Stripe skill does not add its description to sessions in apps/web. This also reduces collisions between similar skills owned by different teams.

For skills that should apply only to certain files without a separate directory, the paths frontmatter field is an alternative:

paths:
  - "services/billing/**"

How do I share skills across several projects?

Three options, from lightest to heaviest:

1. Personal install. Fine if only you need them.

2. --add-dir. Keep a skills repository checked out once and attach it to any session:

git clone [email protected]:your-org/claude-skills.git ~/src/claude-skills
claude --add-dir ~/src/claude-skills

Claude Code loads skills from ~/src/claude-skills/.claude/skills/, and picks up edits there live. Nobody copies files; git pull updates everyone.

3. A plugin. Package the skills in a plugin and publish a marketplace. Teammates install with /plugin install name@marketplace, skills are namespaced, and you can version releases. The team sharing guide covers this in detail, and plugin-marketplace-publisher helps set it up.

Do changes to skills take effect immediately?

Yes, for the standard locations. Claude Code watches ~/.claude/skills, the project’s .claude/skills, and --add-dir directories, so adding or editing a skill there takes effect on the next invocation without restarting.

The exception: if a top-level skills directory did not exist when the session started, for example you create .claude/skills/ for the first time mid-session, run /reload-skills.

Keep in mind that once a skill’s body has been loaded into a conversation, it stays there for the session. Edits apply to the next invocation, not retroactively.

Where do enterprise and plugin skills fit?

Enterprise skills are distributed by your organization’s administrators through managed settings. They sit at the top of the precedence order, so an organization can guarantee that a skill such as security-review behaves the same for everyone, regardless of what individuals have installed. If a personal skill seems to be ignored at work, check whether an enterprise skill with the same name exists.

Plugin skills sit outside the precedence order entirely. Because they are invoked as /<plugin>:<skill>, a plugin can ship a code-review skill that coexists with your personal code-review and the project’s code-review. Claude can still pick a plugin skill automatically when its description matches, so overlapping descriptions remain a problem even when names do not collide.

Common mistakes when choosing a location

• Committing a personal skill by accident. If a skill references /Users/you/scripts/ or your private notes, it does not belong in .claude/skills/. Check paths before committing.
• Keeping a stale personal copy. You install a skill personally, the team later adopts an improved version in the repo, and your old copy silently wins. Delete personal copies when a project version exists.
• Installing everything personally. Each personal skill adds its description to every session in every project. A Django skill does nothing useful in your Go repos; install it in the Django project instead.
• Duplicating across repos. If the same skill is copied into five repositories, it will drift into five versions. Move it to a shared skills directory or a plugin.
• Generic names in shared locations. A project skill named review will collide with someone’s personal review. Prefix shared skills with something specific to the repo or team.

What about claude.ai and the API?

These locations are Claude Code only. Skills uploaded to claude.ai are per user, and skills uploaded through the Claude API are shared across a workspace. None of them sync with each other or with your filesystem. See Skills on claude.ai and the API.

Next steps

• Distribute project skills properly: Share skills with your team
• Fix a skill that is shadowed or missing: Skill not triggering?
• Install methods for each location: How to install Claude Code skills
• Browse skills by category: /skills/