[FEATURE] per-project skill allowlist in settings.json

Resolved 💬 3 comments Opened May 13, 2026 by JahidHasanSagor Closed May 17, 2026

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

When skills are installed globally (~/.claude/skills/), they load in every project regardless of relevance. Projects with their own skill (e.g. career-ops) get interference from unrelated global skills — overlapping triggers, context bloat, and global CLAUDE.md instructions overriding project-level behavior.

Requested: Add an allowed_skills (or blocked_skills) field to project .claude/settings.json:
```
{
"allowed_skills": ["career-ops"]
}

This would let projects opt out of global skills they don't need.

### Proposed Solution

`Two additions to the project .claude/settings.json:`

{
"allowedSkills": ["career-ops"],
"blockedSkills": ["gstack", "review", "ship"]
}

**Behavior:**
  - If allowedSkills is set, Claude only activates skills in that list — all other globally-installed skills are invisible for that
  session
  - If blockedSkills is set, those skills are excluded but everything else remains available
  - Both are optional; omitting them keeps current behavior (all global skills load)
 
**Why this matters UX-wise:**

1. I install a job search skill (career-ops) in my project. I also have gstack installed globally for my dev projects. When I open career-ops, gstack's /browse instruction in ~/.claude/CLAUDE.md overrides career-ops' own web verification logic — silently, with no way to prevent it short of editing the global CLAUDE.md manually.
2. Each globally installed skill adds preamble context at session start. With 5+ skill packs, unrelated skills consume context budget in every project that doesn't need them.

### Alternative Solutions

**The workaround** today is adding a ## Skill Policy block to the project CLAUDE.md telling Claude to ignore specific skills — but that's fragile (it's an instruction, not enforcement) and requires manually updating it every time a new global skill is installed.

A settings-level allowlist would be enforced by the runtime, not by Claude's interpretation of prose instructions.

### Priority

Medium - Would be very helpful

### Feature Category

Configuration and settings

### Use Case Example

_No response_

### Additional Context

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗