[FEATURE] Option to restrict skill loading to project scope only

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Team standardization: When working in a shared codebase, teams want to ensure everyone is running the same set of skills — no more, no less. User-level skills are personal and vary across developers, which makes skill behavior inconsistent across the team. A project-scoped skills-only mode would let teams commit a canonical set of skills to version control and guarantee that's what everyone uses.

Context pollution: Every user-level skill contributes its description to Claude's context, even when completely irrelevant to the current project. A developer with 30+ personal skills will have all of those definitions loaded into every session regardless of the project they're working on. This wastes context budget and creates noise that can interfere with Claude's skill selection.

What I tried

The current permission system allows denying specific skills by name:

{
  "permissions": {
    "deny": ["Skill(unrelated-skill-1)", "Skill(unrelated-skill-2)", ...]
  }
}

This approach is brittle and unworkable in practice:

• It requires knowing and enumerating every user-level skill that should be blocked
• It breaks whenever a team member adds a new personal skill
• It can't be maintained in a shared settings.json since user-level skills differ per developer
• It leaks: any skill not explicitly listed will still load

Proposed Solution

A skillSources (or similar) option in .claude/settings.json:

{
  "skillSources": ["project"]
}

When set, Claude Code would only load skills from .claude/skills/ in the current project, ignoring ~/.claude/skills/ and any plugin/enterprise sources not explicitly listed.

Possible values could mirror the existing settings hierarchy: project, user, enterprise, plugin.

Alternative Solutions

• Union-based permission evaluation: Instead of first-match-wins, evaluate all permissions as a union where explicit allow and deny rules are combined and an explicit allow: ["Skill(x)"] carves out an exception from a broad deny: ["Skill"]. Think Venn diagram: deny covers everything, allow punches a hole in it.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

_No response_