Skill tool doesn't prioritize local .claude/skills/ over parent/global skills

Status Fixed / completed

Maintainer reply None cached

Activity 4 comments · opened Jan 23, 2026 · closed Aug 19, 2026

Description

The Skill tool does not prioritize local .claude/skills/ scripts over parent or global skills with the same name. When invoking a skill that exists both locally and globally, Claude Code executes the global version instead of the local override.

Steps to Reproduce

Have a parent workspace with a skill (e.g., pm-nano/.claude/skills/goodbye.sh)
Create a child repo with a local skill of the same name (e.g., fermi-knowledge-base/.claude/skills/goodbye.sh)
From within the child repo, invoke the skill using the Skill tool: Skill(goodbye)

Expected Behavior

The local skill at fermi-knowledge-base/.claude/skills/goodbye.sh should execute, shadowing/overriding the parent skill.

This follows standard precedent:

Local node_modules overrides global packages
Local .git/config overrides global git config
Local environment variables override system defaults

Actual Behavior

The parent/global skill (pm-nano goodbye) executes instead of the local one. The Skill tool output shows:

Available skills:
- goodbye: PM Session Checkpoint (/goodbye)
- pm: PM Command

The local fermi-knowledge-base/.claude/skills/goodbye.sh is not recognized or is deprioritized.

Impact

This limits the composability and flexibility of the skill system:

Can't have project-specific overrides of workspace-level skills
Forces unique naming for all skills across nested projects
Breaks the expected behavior where "local overrides global"

Workaround

Currently, the only workaround is to:

Use unique skill names (e.g., fermi-goodbye instead of goodbye)
Manually invoke via Bash: bash .claude/skills/goodbye.sh

Both defeat the purpose of skill overrides.

Context

Repository: fermi-knowledge-base (child)
Parent workspace: pm-nano (parent)
Both have .claude/skills/goodbye.sh
Expected: Local skill should take precedence
Actual: Parent skill executes

Suggested Fix

Skill resolution should follow a search path priority:

.claude/skills/ in current working directory
.claude/skills/ in parent directories (walking up)
Global/system skills

This would match standard tool behavior and enable proper local overrides.

View original on GitHub ↗

3 Comments

GeoffNordling · 6 months ago

Hitting this problem also, with user-level vs. project-level skills. I have a personal commit-push skill and a project-level one that handles a two-repo workflow. The project skill should take precedence when I'm in that project.

thomaswitt · 6 months ago

+1 for this problem. I want to have a skill 'ruby-on-rails-architect' which gets overwritten by a specific project because it has different requirements / architecture.

That the GLOBAL skill wins doesnt make any sense and is inconsistent. Should be always CWD > Parent > Global.

That is by the way the case with agents. when I create a user agent that works just fine:

/agents
   User agents (/Users/thomas/.claude/agents)                                                     
   test-override-agent · inherit ⚠ overridden by projectSettings                                  

   Project agents (/Users/thomas/Downloads/agent-override-test/.claude/agents)                    
   test-override-agent · inherit

"overridden by projectSettings" clearly shows that the code gets it right.

rado-arqitech · 3 months ago

+1 on this. I'd also suggest making the precedence configurable rather than hardcoding local-first.

Use case: I have a personal grill-me skill globally with my preferred interview style. Some projects define their own grill-me with domain-specific questions. I want project to win in those repos, but global to win elsewhere.

A fixed local-first rule solves the OP's case but breaks mine. A setting like:

{
  "skillPrecedence": "project" | "global"
}

...would let users choose based on their workflow. Default to "project" (local-first) to match standard tooling conventions, but allow override for teams/users who need the opposite.

Showing cached comments. Read the full discussion on GitHub ↗