Skill files generated for other AI hosts pollute Claude Code's skill scanner

[vschoener]

Problem

When gstack is installed at ~/.claude/skills/gstack/, Claude Code recursively scans the entire directory tree for SKILL.md files. The host-specific skills generated for other AI assistants (Hermes, Cursor, Kiro, OpenCode, Slate, Factory, Agents, OpenClaw) are picked up by this scanner, causing 513 SKILL.md files to be discovered instead of the expected ~49 in my situation.

Impact

Claude Code reports "N skill descriptions dropped" at session start (the exact number varies depending on which host integrations are installed — in my case it was 49–51). This happens because Claude Code hits its context window limit trying to load all the discovered skill descriptions, meaning some skills may not be properly available in the preamble.

Root cause

After installation/update, the following directories are generated inside ~/.claude/skills/gstack/:

~/.claude/skills/gstack/
├── .agents/skills/        ← 46 SKILL.md (for Agents)
├── .cursor/skills/        ← 46 SKILL.md (for Cursor)
├── .factory/skills/       ← 46 SKILL.md (for Factory)
├── .gbrain/skills/        ← 46 SKILL.md (for GBrain)
├── .hermes/skills/        ← 46 SKILL.md (for Hermes)
├── .kiro/skills/          ← 46 SKILL.md (for Kiro)
├── .openclaw/skills/      ← 46 SKILL.md (for OpenClaw)
├── .opencode/skills/      ← 46 SKILL.md (for OpenCode)
├── .slate/skills/         ← 46 SKILL.md (for Slate)
└── openclaw/skills/       ←  4 SKILL.md

These are all gitignored (correctly), but Claude Code doesn't know to ignore them.

Workaround

Manually deleting these directories reduces the count from 513 to ~95:

for dir in .agents .cursor .factory .gbrain .hermes .kiro .openclaw .opencode .slate; do
  rm -rf ~/.claude/skills/gstack/$dir/skills/
done

However, these directories are recreated on the next gstack update.

Suggested fix

One of:

1. Move the generated host skills outside ~/.claude/skills/ — e.g., generate Hermes skills at ~/.hermes/skills/gstack/ (matching globalRoot in hermes.ts) rather than inside the gstack repo itself when it's installed under ~/.claude/skills/.

2. Add a marker file (e.g., .claudeskillsignore or NOSKILL) in each host subdirectory so Claude Code can be taught to skip them — though this would require a Claude Code change too.

3. Generate host-specific skills to a path outside ~/.claude/ unconditionally, regardless of where gstack is installed.

Environment

• gstack version: v1.26.3.0
• Claude Code version: 2.1.142
• gstack install path: ~/.claude/skills/gstack/

[Saisreenivas]

Hitting the same root cause from cursor-agent (Cursor CLI), with a much harder failure mode than Claude Code's "N skill descriptions dropped" warning — adding data here rather than filing a duplicate.

cursor-agent's failure mode is worse than Claude Code's

Claude Code drops some skills gracefully when its context budget runs out. cursor-agent CLI's TUI completely freezes — the spinner shows "Composing" then loops on "Reconnecting…" forever. Underlying error (only visible with agent --debug):

ConnectError: Stream closed with error code NGHTTP2_ENHANCE_YOUR_CALM
[nal_agent_retries] Error not retryable
Connection failed 10 times. Please check your network connection and try again.
turn.outcome: outcome=error, error_code=ERR_HTTP2_STREAM_ERROR

With network.useHttp1ForAgent: true it surfaces more cleanly as Bad Request: Append data exceeds maximum size of 52428800 bytes.

Threshold characterization (byte-based)

Held cursor-agent baseline constant (14 plugin/cloud-rule skills, ~0.7 MB), varied N synthetic SKILL.md files of 50 KB each:

Total skills	Total skill bytes	Result
219	~10.95 MB	pass
220	~11.0 MB	fail (NGHTTP2_ENHANCE_YOUR_CALM)
287	~14.4 MB	fail
512	~25.6 MB	fail
32 × 1 MB	~20 MB	fail
62 × 1 MB	~50 MB	fail

Failure is byte-based: 32 × 1 MB and 220 × 50 KB hit the same ceiling. cursor-agent TUI dies above ~11 MB of total skill content. A single gstack install with the 9 host wrappers blows past that immediately.

What it took to make cursor-agent's TUI usable on my machine

Pruned from 1408 → 218 SKILL.md (77 MB → 9.28 MB) by removing the .hermes/.openclaw/.opencode/.factory/.gbrain/.kiro/.slate/.cursor/.agents wrapper dirs from both my gstack installs (~/.agents/skills/gstack/ and ~/.claude/skills/gstack/). After that, TUI works (turn.outcome: outcome=success). The OP's workaround works for cursor-agent too — the prune just needs to cover both install roots, not only ~/.claude/skills/gstack/.

On the suggested fixes

Strongly +1 for fix #1 (write host-specific skills to ~/.<host>/skills/, not nested inside the gstack install). The nested wrapper pattern multiplies the cost on every AI host that uses a recursive **/SKILL.md glob — Claude Code, cursor-agent, presumably Codex, and any future agent loader. Centralizing each host's skills under its own root dir avoids the issue at the source.

Fix #2 (marker file) needs cooperating consumers and adds a coordination burden. Fix #3 unifies on a stable layout. Either is much better than the status quo.

Parallel Cursor-side issue

I'm filing a parallel report with Cursor asking them to (a) honor .cursorignore in the SKILL discovery glob and (b) add a cli-config.json option to scope skill roots. Even after gstack restructures, recursive skill globbing across $HOME will hit anyone who later installs a different sufficiently large skill pack. Forum thread: https://forum.cursor.com/t/cursor-agent-cli-tui-fails-with-nghttp2-enhance-your-calm-once-skill-payload-exceeds-11-mb-no-scoping-option/161534.

Environment

• gstack: installed at ~/.agents/skills/gstack/ AND mirrored at ~/.claude/skills/gstack/ (so the wrapper bloat is doubled in my case)
• cursor-agent: 2026.05.24-dda726e, Composer 2.5
• macOS 15.4 (Darwin 25.4.0), arm64
• Other hosts installed: Hermes, OpenClaw, OpenCode, Factory, GBrain, Kiro, Slate, Claude Code