When a developer wants a variant of a team skill — extra checks, different output format, domain-specific additions — they create a personal skill in ~/.claude/skills/. It is user-scoped, not version-controlled, and available only to that developer across all their projects.
The one rule that must not be broken: give it a different name than the project skill.
How Personal Skills Work
| Location | Scope | Version-controlled | Visible to team |
|---|---|---|---|
.claude/skills/review/ | Project | Yes | Yes |
~/.claude/skills/my-review/ | User | No | No |
A developer who wants a security-focused version of /review creates ~/.claude/skills/security-review/SKILL.md. They invoke /security-review for their enhanced version, while the team continues using /review unchanged.
The creation process is straightforward: copy the shared skill’s SKILL.md, rename the directory, add your customizations. Starting from the shared skill ensures the personal variant includes the team’s proven base functionality.
The Shadowing Problem
If a developer names their personal skill deploy-check — identical to the project’s /deploy-check — the personal version shadows the team skill on that developer’s machine. When they invoke /deploy-check, they get their personal variant, not the team’s.
One team discovered this when a developer’s CI runs started missing security validation. The developer had created a personal deploy-check skill without the security step. On their machine, every /deploy-check invocation ran their personal version. Other team members saw different results because they were running the project skill.
This is not a bug. Claude Code does not automatically namespace personal skills by prepending the username. If the names collide, the personal version takes precedence on that developer’s machine.
Naming Convention
The fix is simple: use distinct names. Two common patterns:
- Descriptive prefix:
my-review,my-deploy-check - Initials prefix:
jd-review,km-extract
One team of 6 developers tracked adoption over a month. Three developers created personal skill variants. All used initial-prefixed names. Shared skill usage stayed unchanged at ~20 invocations/day. Zero shadowing incidents.
The prefix convention is lightweight and effective. No registry, no approval process, no centralized enforcement needed.
What Does Not Belong in User Scope
Personal skills are for individual preferences — formatting style, extra domain-specific checks, output format variations. They supplement shared skills, not replace them.
Things that should NOT be personal skills:
- Team-critical workflows the whole team depends on (put in
.claude/skills/) - Standards that must apply to everyone (put in CLAUDE.md)
- CI/CD workflows that must produce consistent results (put in
.claude/skills/)
A developer who puts /deploy-check in ~/.claude/commands/ and expects the whole team to have it creates the “works on my machine” problem. Team-critical workflows must be in project scope.
What Does Not Belong in Project Scope
The reverse is also true. A senior developer proposes: “All skills should be in the project repo for visibility. Personal skills create hidden configuration.”
This would clutter the shared project config with 10 developers’ individual formatting preferences. Personal skills do not affect other developers — they only change behavior on the developer’s own machine. The debugging concern is valid (if one developer’s output diverges, the team may need to ask about their config) but is better solved through communication than by eliminating personal customization.
Extending, Not Replacing
Personal skills add to the team’s workflow. After introducing personal skills, one team measured:
- Shared skill usage: unchanged
- Personal skill adoption: 3 of 6 developers
- Naming conflicts: zero
Personal skills supplemented shared ones. Developers used both — shared skills for standard team workflows, personal skills for their customized needs.
One-liner: Personal skills go in ~/.claude/skills/ with a distinct name — same name as a project skill causes shadowing, which is the only real risk.