[FEATURE] Skill profiles: role-based scoping of active skills

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

As teams build out skill libraries, the number of skills in a project grows well beyond what any single role needs in a session. In our monorepo we have 34 skills spanning PM work (sprint analysis, PRD authoring, ticket readiness evaluation), development work (deployments, code migrations, test runners, infrastructure), and shared utilities. Today, every skill is always visible and can auto-invoke regardless of what the user is actually doing.

This creates three concrete problems:

1. Unwanted auto-invocation. When a PM is reviewing sprint health, development-only skills (deployment, code migration, test runners) can auto-fire on ambiguous prompts. The model sees all skill descriptions and occasionally picks the wrong one. There's no way to tell Claude "I'm doing PM work right now, ignore dev skills."

1. Context window waste. Every skill's description is loaded into the system prompt on every session. With 34 skills, that's significant token overhead — tokens that could be used for actual task context. Users who only need 10 skills still pay the context cost of all 34.

1. Cognitive overhead for the model. More skills means more decision surface. The model must evaluate every skill's trigger conditions on every message. Reducing the active set to role-relevant skills would improve both accuracy and latency.

This is distinct from disabling auto-triggering globally (#30355) — we still want auto-triggering, just scoped to the right subset. And it's complementary to deferred skill loading (#29711) — even with lazy loading, the model still sees all descriptions and can invoke any of them.

Proposed Solution

A named profile mechanism that controls which skills are active in a session. Profiles would be defined in configuration (not code) and switched via CLI flag or command.

Defining profiles (in settings.json, .claude/settings.json, or a dedicated config):

{
  "profiles": {
    "pm": {
      "description": "Planning, reporting, sprint analysis",
      "skills": ["creating-prds", "evaluating-sprint-*", "gathering-requirements", "reading-pull-requests"]
    },
    "dev": {
      "description": "Coding, testing, deployments",
      "skills": ["building-*", "creating-pull-requests", "running-tests", "upgrading-*"]
    },
    "all": {
      "description": "No restrictions (default)",
      "skills": ["*"]
    }
  }
}

Switching profiles:

# At session start
claude --profile pm

# Mid-session (slash command)
/profile pm

# Show current profile and available profiles
/profile --list

Behavior when a profile is active:

• Only listed skills appear in the system prompt and can auto-invoke
• Unlisted skills are invisible to the model (not denied — just not loaded)
• Glob patterns (evaluating-*) keep profiles maintainable as skills are added
• The all profile (or no profile) restores default behavior — all skills visible

Key design considerations:

• Profiles should be additive include lists, not deny lists. "Show me only these" is simpler and safer than "hide everything except these"
• Profile definitions should live in project-level config (shareable with the team) with optional user-level overrides
• Switching profiles mid-session should be lightweight — no restart required
• Skills excluded by a profile should not consume context tokens at all (not loaded, not just hidden)

Alternative Solutions

What we're doing today: We wrote a shell script that computes the deny set (ALL_SKILLS − PROFILE_SKILLS) and writes Skill(name) entries to permissions.deny in .claude/settings.local.json. It works but has significant drawbacks:

• Deny-list approach is fragile. Every new skill must be added to the script or it escapes all profiles. An include-list approach would be safer (new skills default to invisible in scoped profiles).
• Requires restarting the session. The deny list is read at startup; you can't switch roles mid-conversation.
• External to Claude Code. It's a bash script manipulating a JSON config file — there's no Claude Code awareness of "profiles" as a concept, no /profile command, no way for the model to know which profile is active.
• Permissions.deny is a blunt instrument. It's designed for security boundaries, not workflow preferences. Using it for role scoping feels like an abuse of the mechanism.

Other workarounds considered:

• Setting disable-model-invocation: true on skills individually — tedious and doesn't help with context waste
• Maintaining separate .claude/ directories per role — heavy, error-prone to keep in sync
• Using subagent-scoped skills (#30278) — solves a different problem (agent isolation, not user role switching)

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Scenario: Team lead who alternates between PM and dev work

1. Monday morning — sprint planning. The lead starts Claude Code to analyze sprint readiness:

``bash
claude --profile pm
`
Only PM skills are active: sprint evaluation, PRD creation, ticket readiness checks, requirements gathering. When they say "check if the sprint is ready," Claude auto-invokes evaluating-sprint-readiness` without confusion from 24 dev-only skills.

1. Monday afternoon — coding. The lead switches to development:

``bash
/profile dev
`
Now deployment, testing, migration, and infrastructure skills are active. PM skills are invisible. When they say "run the tests," Claude invokes running-tests without competing with evaluating-sprint-readiness` for attention.

1. The team has 40+ skills. Without profiles, the lead's every session loads all 40 descriptions (~3,000 tokens of skill metadata), and the model occasionally auto-invokes the wrong skill category. With profiles, each session loads only the 10-15 relevant skills, and auto-invocation accuracy improves because the decision surface is smaller.

Scenario: Onboarding new team members

A team defines a junior-dev profile that excludes infrastructure and deployment skills (which require elevated access). New developers get a focused set of skills appropriate to their role without the team needing to modify skill files or permissions per person.

Additional Context

• Related issues: #7075 (full profile system with memory/hooks/settings isolation — this request is a lighter-weight, skills-focused subset), #30278 (subagent-scoped skill directories), #24000 (MCP profiles for tool switching), #29711 (deferred skill loading), #30355 (global auto-trigger disable)
• Scale context: Our project has 34 skills today and is growing. Teams with fewer skills may not feel this pain yet, but skill libraries grow fast once the pattern is adopted — especially in monorepos where multiple services each contribute domain-specific skills.
• This complements existing proposals. If #7075 (full profiles) ships, skill scoping could be one dimension of it. If profiles are too big to ship at once, skill profiles alone would deliver significant value as an incremental step.