Personal Claude Code Skills: Customise Without Affecting Your Team

Why personal Claude Code skills exist

Personal claude code skills give you a private place to bend a workflow to your own habits without imposing those habits on anyone else. The shared skills committed to a project .claude/skills/ folder are a team contract: change one and every teammate inherits the change on their next pull. That is the right behaviour for a genuine team standard, but it is the wrong behaviour when you simply prefer a chattier commit message or an extra confirmation step. The home-directory skills folder is where that personal preference belongs.

The location rule mirrors the one you learned for slash command directories: the project folder is shared through git, the home folder is yours alone. Skills add one extra wrinkle worth knowing, a precedence order, which is what makes private customisation clean rather than messy.

Where personal skills live and how precedence works

Skills can be stored at several levels, and where you put one decides who can use it.

• Personal, ~/.claude/skills/<name>/SKILL.md: applies to all your projects, visible only to you.
• Project, .claude/skills/<name>/SKILL.md: committed to the repository, shared with the team, scoped to that project.
• Enterprise / plugin: managed organisation-wide or bundled in a plugin.

When two skills share the same name across levels, precedence resolves the clash: enterprise overrides personal, and personal overrides project. That ordering is the key to private customisation. A personal skill named commit will quietly take precedence over the project commit skill for you, while every teammate continues to get the project version, because your home folder was never committed.

The two strategies for customising privately

There are exactly two safe ways to personalise, and both leave the shared skill untouched.

1. Different name (coexist). Copy the project skill into ~/.claude/skills/ under a new folder name such as commit-verbose, then edit your copy. Now /commit (the team version) and /commit-verbose (yours) both exist, and you choose which to invoke. This is the approach the knowledge point recommends because it avoids any ambiguity about which skill is running.
2. Same name (shadow). Copy the project skill into ~/.claude/skills/ keeping the same folder name, then edit it. Personal precedence means your version wins for you while teammates keep the project one. This is tidy when you want your variant to be the default behind the familiar command.

Both strategies share the same golden rule: you never edit the file in the project .claude/skills/ folder for a personal preference, because that file is committed and your edit would ship to everyone.

The full precedence chain

Personal customisation only works cleanly because skills resolve in a defined order, so it pays to know the whole chain rather than just the personal-over-project step. Skills can exist at four levels, and when two share a name the more specific level wins in this order: enterprise overrides personal, personal overrides project, and plugin skills sit in their own namespace so they never collide. Enterprise sits at the top because organisations need to be able to mandate behaviour that an individual cannot quietly override. Personal sits above project because the whole point of a home-directory skill is to let you tailor your own experience on top of the shared baseline. Plugin skills use a plugin-name:skill-name namespace, which is why installing a plugin never silently shadows one of your commands.

For this knowledge point the operative slice is the middle: personal beats project. That single fact is what guarantees a same-named personal variant takes effect for you while leaving the committed team skill untouched for everyone else. If you ever see surprising behaviour where your edits to a project skill seem ignored, the first thing to check is whether a personal skill of the same name is shadowing it from your home folder.

Discovery and live reload

Personal skills are discovered automatically, just like project skills, so there is no registration step. Claude Code watches the skill directories during a session, which means adding, editing, or removing a skill under ~/.claude/skills/ usually takes effect within the current session without a restart. The one exception is creating a top-level skills directory that did not exist when the session began; because the watcher was not set up for a directory that was absent at startup, you restart so it can begin watching. In day-to-day use this makes iterating on a personal variant fast: you tweak the SKILL.md, re-invoke it, and see the change immediately. That tight loop is part of why the home folder is the natural place to experiment before anything is ready to be shared.

Promoting a personal skill to the team

Customisation runs in both directions. The home folder is not only where you keep private preferences; it is also where good ideas incubate before they become team standards. A skill that starts life as a personal helper can graduate: once it has proved itself, you copy it from ~/.claude/skills/ into the project .claude/skills/ folder, refine the description and tool scope for general use, and commit it so the whole team inherits it. This promotion path is worth remembering because it reframes the personal folder as a staging area, not a dead end. The same precedence rules then apply in reverse: if you keep your private copy under the same name after promoting it, your personal version will continue to shadow the new team one for you until you delete it.

When personal is the wrong choice

The flip side of this knowledge point is recognising when a skill should not be personal. If a workflow encodes a team standard, a compliance requirement, or anything other people depend on for consistency, hiding it in your home folder defeats the purpose, because no teammate can see or run it. Personal is for preference, not for policy. A good test: if you would be unhappy for a teammate to do the same task differently, the skill belongs in the project folder where git enforces consistency. Reserve the home folder for the genuinely personal, the chattier commit message, the extra confirmation prompt, the scratch helper that only makes sense for how you work.

Common misreadings to avoid

The same rule applies to commands

Everything in this knowledge point carries over to plain slash commands, because they obey the same two-folder split. A command in ~/.claude/commands/ is personal and follows you across projects; a command in the project .claude/commands/ folder is shared through git. So if you want a private tweak of a team command, you apply the identical strategy: copy it into your home commands folder under a new name to coexist, or under the same name to take precedence for yourself, and never edit the committed team file for a personal preference. Because commands and skills now share a namespace and a precedence model, the mental model you build here is reusable across both. The one detail to keep straight is that a skill and a command of the same name resolve in the skill favour, so if you maintain a personal skill and a personal command that happen to collide, the skill wins, a rare situation, but one worth recognising if a personal command ever seems to be ignored.

This consistency is deliberate and useful: rather than memorising separate rules for commands and skills, you learn one rule about project versus personal folders and apply it everywhere. Whenever a customisation is genuinely yours, it lives in your home directory; whenever it is a shared contract, it lives in the committed project folder. That single principle is the backbone of every personal-customisation question in Domain 3.

How this shows up on the exam

TS 3.2 lives in Domain 3 (20% of the exam), and personal customisation questions arrive through Scenario 2 most often. The recurring trap is a developer who modified a project-level skill to suit a personal preference and inadvertently changed behaviour for the whole team. The correct response is always to relocate the preference into a personal variant under ~/.claude/skills/, choosing a distinct name to coexist or the same name to shadow. Keep the location rule and the precedence order in mind, and these become straightforward. The same reasoning scales up into the command-and-skill design scenarios that ask you to place several artefacts at once.

Watch and learn

Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.

Official · Anthropic AcademyOpen full lesson in Academy

Sharing skills

Why watch: Sharing versus keeping skills personal in ~/.claude is the personal-customisation-versus-team-sharing concern this KP covers.

More videos for this concept

Sharing skills

Introduction to Agent Skills

Creating custom Skills with Claude

Anthropic

How to Use Claude Code Skills Like the 1% (it's easy actually)

Simon Scrapes

Building a custom Claude Code Skill from scratch

The Design Project