[BUG] Only the oldest 2 of 35 custom `.skill` files register — new `.skill` files silently fail to load

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 1 comment · opened Jul 30, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Environment

  • OS: Windows 11 Pro (10.0.26200)
  • Shell: Windows PowerShell 5.1
  • Claude Code: CLI

Summary

~/.claude/skills/ contains 35 custom .skill ZIP files. Only the 2 oldest ones (first ever added to the folder, months ago) show up in the available-skills listing and can be invoked via the Skill tool. Every other .skill file added since then — including ones added and verified structurally identical to the working ones — fails to register, with Skill("<name>") returning Unknown skill.

Steps to reproduce

  1. Add a new .skill file to ~/.claude/skills/ — a ZIP archive containing <name>/SKILL.md (forward-slash entry path), with YAML frontmatter name: <name> matching the filename exactly.
  2. Fully restart the Claude Code CLI process (not just start a new conversation).
  3. In a new conversation, check the available-skills listing, or call the Skill tool with the new skill's name.

Expected behavior

The new skill appears in the available-skills listing and can be invoked.

Actual behavior

The new skill does not appear in the listing, and invoking it returns Unknown skill. Only the 2 skills first added to the folder (months prior) ever load, regardless of how many valid .skill files are added afterward.

Diagnostics already performed (all ruled out as the cause)

  • ZIP structure: extracted every .skill file in the folder and confirmed the failing ones have the identical structure to the working ones — single entry <name>/SKILL.md, forward-slash separator, valid ZIP.
  • Frontmatter collisions: confirmed every .skill file has a unique name: field in its YAML frontmatter matching its filename exactly — no duplicates anywhere in the folder.
  • Frontmatter format: spot-checked multiple failing files against the 2 working files — both use the identical description: > YAML folded-block style; not a format difference.
  • Config-level cap/allowlist: grepped ~/.claude.json case-insensitively for "skill" — no installedSkills/skillsRegistry/allowlist key exists. Only hits are unrelated (tengu_skills_dashboard_enabled, an unrelated built-in plugin name, and a skillUsage usage-tracking block).
  • skillUsage tracking: this block contains exactly 2 entries — the 2 working skills — with real usageCount/lastUsedAt data from when they were first set up. No entries exist for any of the other 33 .skill files, suggesting they were never even considered for registration, not that they registered and failed silently elsewhere.
  • settings.json / settings.local.json: no skill-related allow/deny/cap configuration exists in either file.
  • Stray duplicate skill directories: checked for loose (non-ZIP) skill folders elsewhere on the filesystem that might shadow-load instead of the ZIPs — none found (only leftover extraction scratch copies in a temp folder, not a real source).
  • Full CLI process restart: fully closed and reopened the Claude Code CLI (not just a new conversation within the same running process) and retested — result unchanged, new skills still fail to register.
  • File count drift: the number of .skill files reported by Get-ChildItem ~/.claude/skills/*.skill has varied across sessions on the same machine without any files being added or removed (31 → 34 → 35 observed across passes) — not diagnosed, but noted as possibly relevant to how the skill directory is being enumerated/cached.

Hypothesis

Skill discovery/registration may be capped or broken at a level below any user-editable config — possibly limited to skills present at first-ever setup, with everything added since silently failing to register regardless of file validity.

Additional notes

Happy to provide the exact .skill file structure/frontmatter (with any client-identifying content redacted) if useful for reproduction.

What Should Happen?

Expected behavior

The new skill appears in the available-skills listing and can be invoked.

Error Messages/Logs

## Actual behavior
The new skill does not appear in the listing, and invoking it returns `Unknown skill`. Only the 2 skills first added to the folder (months prior) ever load, regardless of how many valid `.skill` files are added afterward.

Steps to Reproduce

  1. Add a new .skill file to ~/.claude/skills/ — a ZIP archive containing <name>/SKILL.md (forward-slash entry path), with YAML frontmatter name: <name> matching the filename exactly.
  2. Fully restart the Claude Code CLI process (not just start a new conversation).
  3. In a new conversation, check the available-skills listing, or call the Skill tool with the new skill's name.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.220

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Hypothesis

Skill discovery/registration may be capped or broken at a level below any user-editable config — possibly limited to skills present at first-ever setup, with everything added since silently failing to register regardless of file validity.

Additional notes

Happy to provide the exact .skill file structure/frontmatter (with any client-identifying content redacted) if useful for reproduction.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗