Feature request: per-subagent skill allowlisting (not just preloading or full block)

Status Open
Maintainer reply None cached
Activity 2 comments · opened Jul 29, 2026

Feature request: per-subagent skill allowlisting (not just preloading or full block)

Problem

Every subagent launched via the Agent/Task tool builds a fully fresh system prompt — confirmed via cache_creation_input_tokens in subagent transcripts, which show 20-32k tokens written to a new cache entry on the first assistant turn of each launch, every time, even across subagents in the same session. A large share of that (roughly 7-8k tokens in a config with ~70 active skills) is the full enabled-skills catalog listing, injected regardless of whether the subagent's task needs 1 skill or 0.

Current state

  • Custom subagent definitions (.claude/agents/*.md frontmatter) support a skills: field, but per the docs this only controls which skills are preloaded (injected in full up front) — it does not restrict which skills the subagent can see or invoke. The subagent still gets the entire enabled-skill catalog listing via the Skill tool.
  • The only way to reduce this today is all-or-nothing: remove Skill entirely from a custom subagent's tools: allowlist, which blocks every skill, not just the irrelevant ones.
  • There's no Agent-tool call-site parameter to scope skills per invocation either.

Request

Add a granular skill allowlist for subagents — symmetric to the existing tools: restriction — e.g.:

---
name: my-agent
tools: [Read, Grep, Bash]
skills: [only-these-skill-names]   # today: preload-only, would become: restrict-to
---

or a separate field (e.g. skillAllowlist:) so skills: keeps its current preload meaning. This would let users with large personal skill libraries (dozens of project/plugin skills, common for power users with many installed plugins) scope subagents to only the relevant subset, cutting fixed per-launch context/cache-write cost without losing the rest of the skill catalog in the main session.

Why it matters

For users running frequent subagent-based workflows (research agents, review agents, orchestration patterns spawning many short-lived subagents), this fixed catalog-listing cost is paid on every single launch and scales with the number of installed skills/plugins — it's a fixed tax unrelated to the actual task, and currently has no lever besides trimming the global skill count (which trades away functionality for everyone, not just for that one subagent's task).

View original on GitHub ↗

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