[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_This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗