Skills system-reminder injection wastes massive tokens for power users with many skills

Problem

Users with many custom skills (100+) experience massive token waste because the full skill list is re-injected in every <system-reminder> block. These system reminders fire on nearly every tool result, meaning the same skill descriptions are repeated dozens of times per session.

Impact

For a user with 246 skills (~30-50K tokens of descriptions), in a session with 40+ tool calls:

• ~1.5-2M tokens consumed by repeated skill metadata alone
• At Opus 4.6 pricing, this is significant real cost for zero value
• Context window is polluted with noise, reducing space for actual work content
• The skill descriptions don't change between messages — re-injection is pure waste

Current Behavior

Every <system-reminder> block includes the full skill list:

<system-reminder>
The following skills are available for use with the Skill tool:

- skill-1: [full description...]
- skill-2: [full description...]
... (246 skills, ~30-50K tokens)
</system-reminder>

This fires on nearly every tool result (Bash, Read, Write, Glob, Grep, etc.), multiplying the cost by the number of tool calls per session.

Expected Behavior

Skill descriptions should be injected once at session start, not on every system reminder. Alternatively:

1. Lazy loading: Only inject skill descriptions relevant to the current task context (3-5 skills max)
2. Deferred skills: Use the existing <available-deferred-tools> mechanism to defer skill descriptions, not just tool schemas
3. Hash-based caching: Inject skills once, then only re-inject if the skill set changes
4. User-configurable skill groups: Let users define which skills are active for a given session

Workaround

None available. Users cannot control which skills are injected or how often. The only option is to have fewer skills, which defeats the purpose of the skill system.

Environment

• Claude Code CLI
• Opus 4.6 (1M context)
• 246 registered skills via .claude/settings.json
• Long sessions with many tool calls (typical for agentic workflows)

Additional Context

The <available-deferred-tools> mechanism proves Anthropic can defer tool metadata until needed. Applying the same approach to skill descriptions would solve this issue. The skill descriptions are static per session — they never change between messages, making repeated injection purely wasteful.