Project skills silently dropped beyond ~28 limit — no warning or error

Description

When more than approximately 28 project skills are configured in ~/.claude/skills/, the excess skills are silently excluded from the session's available tools. There is no warning, no error message, and no log entry — they simply don't appear in the session context.

Steps to Reproduce

1. Create 30+ valid skill directories (each with a SKILL.md)
2. Symlink them into ~/.claude/skills/
3. Start a new Claude Code session
4. Observe the system-reminder — only ~28 skills appear in the available skills list
5. Call Skill("one-of-the-missing-skills") — returns Unknown skill: <name>

Expected Behavior

Either:

• All valid skills should be discoverable, OR
• If there's a hard limit, a clear warning should be surfaced (e.g., "Loaded 28/31 skills. The following were not loaded: X, Y, Z")
• Ideally, a configuration option to control priority or selection

Actual Behavior

• ~28 skills load; the remainder are silently dropped
• No feedback mechanism — no warning, no log, no config
• Skill() programmatic calls to dropped skills fail with "Unknown skill"
• The /skill-name slash command still works (reads SKILL.md from disk), but this bypass isn't available for programmatic cross-skill invocation
• Selection criteria for which skills are kept vs dropped is opaque (not alphabetical, not by file size, not by mtime)

Impact

• Silent cross-skill breakage: Skills that invoke other skills programmatically via Skill() fail with no indication of why
• Invisible state: Users cannot tell which skills loaded without inspecting the system-reminder manually
• Unstable equilibrium: Adding one new skill can silently break an existing one elsewhere
• Hard to diagnose: The skill exists on disk, the symlink is valid, SKILL.md is present — everything looks correct, but it doesn't work

Environment

• Claude Code (latest, March 2026)
• macOS (Darwin 24.6.0)
• 31 project skills via symlinks in ~/.claude/skills/

Suggestions

1. Surface the limit — a runtime warning when skills exceed the cap would save significant debugging time
2. Allow priority configuration — let users specify which skills take precedence (e.g., via settings.json)
3. Consider lazy loading — load skill descriptions on-demand rather than all-at-once at session start (similar to Cursor's rule loading strategies: alwaysApply, description-based, globs-based, manual)
4. Document the limit — even just a note in the docs would help

Workarounds

For anyone hitting this today:

1. Remove symlinks for skills that are only user-invoked (never called programmatically by other skills) to stay under the cap
2. Add fallback logic in cross-skill calls: if Skill() returns "Unknown skill", read the SKILL.md file directly and follow its instructions