claude-code - 💡(How to fix) Fix [FEATURE] per-project skill allowlist in settings.json [1 comments, 2 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• 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