`Skill` tool returns include full available-skills catalog (~150 entries) as system-reminder on every invocation, polluting context with duplicate information

Resolved 💬 3 comments Opened May 5, 2026 by ktimesk1776 Closed May 9, 2026

Description

Each invocation of the Skill tool (e.g., Skill(skill: "skill-creator", ...), Skill(skill: "kk-coding", ...), etc.) returns a tool result that includes a <system-reminder> block at the bottom containing the COMPLETE list of available skills installed on the user's system (~150 entries with one-line descriptions for each).

This information is already loaded at session start and visible to the model. Re-emitting it on every skill invocation is duplicate noise.

Expected behavior

The Skill tool result should NOT re-emit the full available-skills list. Acceptable patterns:

  • Emit nothing about skills (the list is already in context).
  • Emit a short "delta" only if new skills became available since session start.
  • Emit a single-line summary like "(N skills available)" rather than the full catalog.

Actual behavior

Every Skill tool invocation returns the full catalog as a system-reminder. On a long session with multiple skill invocations, this adds ~5,000-10,000 tokens of duplicate noise per invocation, totaling tens of thousands of tokens of context pollution.

Impact

  • Token cost: Significant on Opus and on Sonnet 1M-context. A 4-invocation session can waste ~30-40K tokens on duplicates.
  • Cache efficiency: Cache misses likely after each duplicate emission since system-reminder content varies slightly.
  • Context capacity: On long-running sessions (hours, dozens of skill invocations), this can meaningfully eat into available context.

Reproduction steps

  1. In a Claude Code session, invoke any Skill tool, e.g., Skill(skill: "any-installed-skill").
  2. Observe the tool result — at the bottom is a <system-reminder> block listing all installed skills.
  3. Invoke a different skill — same block re-appears.
  4. Sample the response sizes: each block adds ~5-10K tokens depending on how many skills are installed.

Environment

  • Claude Code CLI (any version) with skills installed.
  • User had ~150 skills installed across ~/.claude/skills/, superpowers:*, compound-engineering:*, plugin namespaces. Severity scales with skill count.

Severity

Medium. Not a correctness bug; a performance/cost bug. But meaningful for users running long agent sessions or paying-by-token workflows.

Suggested fix scope

Three options ordered by simplicity:

  1. Suppress entirely. Don't re-emit the skill list on Skill tool results. The model already has it from session start.
  2. Delta only. Emit only newly-installed skills since session start (likely empty in most sessions).
  3. Token-aware suppression. Suppress when context utilization exceeds a threshold; emit when low.

Option 1 is cleanest. Option 2 preserves "you can install skills mid-session" UX but is more complex.

Real-world severity evidence

In RISM Session 89 (2026-05-05), the user invoked 4 skills during a single workflow (/kk-coding, /skill-creator, plus side-effect invocations from skill expansions). Each invocation re-emitted the full ~150-entry catalog. Estimated duplicate token cost: ~30-40K tokens out of ~1M context. On a typical 5-7-day weekly cycle of heavy use, this multiplies into hundreds of thousands of duplicate tokens.

View original on GitHub ↗

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