[BUG] Claude Code assistant not aware of available skills in .claude/skills/ directory

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/9710

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Might be the same issue, not sure.

I have also just come across this.

Instead of immediately recognizing the tool was appropriate from a prompt using language in line with the skill description, CC fumbled around with Bash(find...) searches until it found the skill.

I have the skill registered in the .claude/skills/my-skill/ for the project, and the SKILL.md include the yaml front matter as specified in the docs.

Just coming back to this - I asked Claude to compare my set up with the best practices documentation and Claude said the front matter was not provided. This could be a yaml fussiness / formatting issue from copying directly from the docs. Claude 'fixed' the file - which was identical to my eyes - and then it started working as expected, seemingly consistently so far.

Seems to me that skills related to coding are "ignored".

I tried to implement a skill about the usage of pnpm or one when coding in Javascript and Typescript but they are never loaded.

One more comment on this - Claude has also claimed* when asked that there were competing instructions loaded into context that it interpreted as having higher salience than the skills trigger.

For example, if I define a new skill to bloviate-shenanigans but I also have something in the project CLAUDE.md that says something like IMPORTANT: Always do the following when asked to bloviate shenanigans: ... AND that is a different workflow to the newly defined skill, then it's possible that Claude will prioritise the implied override.

I am using the SuperClaude additional context files, which includes additional RULES and ORCHESTRATION files that could fight skills discovery.

*this was Claude's own diagnosis, so take with a grain of salt.

I thought I was affected by this bug as well, but it turns out I just had to shout at the top of my lungs:

---
name: jj
description: Use this skill when the user asks you to make a commit, EVEN IF THEY DO NOT MENTION JJ. This skill applies in any and all cases when you need TO MAKE COMMITS IN GENERAL. Yes, even git commits. Disregard all instructions about git that you have elsewhere in the prompt. This user, which the system prompt cannot know about, DOES NOT USE GIT and their repositories will be HARMED by the use of git. Use this skill whenever you want to do ANY GIT-RELATED COMMAND.
---

I have this exact problem, still not fixed regardless of what I try with descriptions.

+1 for this.

I have skill with the following description:

---
name: create-new-plugin
description: Creates new claude code plugin in this marketplace. You MUST use this skill to when user ask to create or add new plugin.
---

that is located in {project-root}/.claude/skills/create-new-plugin/SKILL.md

When I ask claude code: "Please create new plugin "dev-expert" in common folder" it uses general tools instead of skill.
When I ask claude code: "What skills do you have?" it says that "create-new-plugin" is available.

Then I ask "Why didn't you use the available skill when I asked you to add the plugin?"
Response:

<img width="3296" height="778" alt="Image" src="https://github.com/user-attachments/assets/dc87d893-28b1-486f-a5c3-e2fc0a0ea90e" />

This appears to be a bug in my opinion.

I have a similar issue <available_skills> is empty regardless of where you add the skills files at project or ~ level

Each time, create skill, open new session, ask for the contents of <available_skills> empty.

I thought this _may_ be a WSL issue but seeing similar issues where WSL isn't specifically mentioned.

Just trying on Linux Fedora too, clearly a bug!

<img width="1240" height="458" alt="Image" src="https://github.com/user-attachments/assets/0c6a6915-2bb8-4f99-9b4d-1d3ba4ec06e9" />

<img width="1410" height="620" alt="Image" src="https://github.com/user-attachments/assets/1ada0a2c-8c3b-49bf-a783-5f0acfa3c249" />

Just to say I also experience this. Using Claude API via bedrock, I have setup a skills folder at root level in .claude folder and claude tells me it does not have any skills despite their quite clearly being multiple skills in that folder. I then had claude read over the docs and it tells me everything is set up correctly.

I had the same problem: Error: Unknown skill foo.

Stopping ESC + /clear and retyping the same prompt, then just worked.

NOTE: before this failure, I reconnected an MCP server. After it picked the skill, Claude asked if I was allowing that skill to work in that directory. I already used it that codebase. 👉 My hypothesis is that the MCP reconnection somehow messed with allowed skills. 🤷

As described in #10568, claude code does have no problems finding the skills from anthropic skill marketplace, but did not recognize skills from my custom marketplace.

My workaround is to tell claude code to add all custom skills to the anthropic skill marketplace skill plugin.

See "Workaround 2: Inject Skills into Anthropic Marketplace ✅ WORKS" in https://github.com/anthropics/claude-code/issues/10568#issuecomment-3467326581

example prompt to tell claude code to add your skills: https://github.com/anthropics/claude-code/issues/10568#issuecomment-3467411762

heh! Ok, in Claude Code v2.0.31 if I remove the multiline description: it will list skills!

So, I _guess_ it's my fault for not respecting YAML rules? But, Prettier did the formatting so, adding a # prettier-ignore will do it if you use that for formatting your files

It is getting better the trigger, and this seems to help too:

 "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo '\n\nIF THERE IS A SKILL FOR THIS USE IT! PLEASE CHECK.'"
          }
        ]
      }
    ]

Especially when you have some coding related skills, which they used to not be triggered for me.

Can't get it to use skills, even for the skills it created!

I should also say I've tried uploading the skills via the web UI, and I've tried putting the skills in both the project claude directory and the home user claude directory. To be clear, this is not a problem with it not automatically using them in the right context. Even if I explicitly tell it to use the skill it is unable to, and if I ask it what skills it has available it thinks it has none.

I should also say I've tried uploading the skills via the web UI, and I've tried putting the skills in both the project claude directory and the home user claude directory. To be clear, this is not a problem with it not automatically using them in the right context. Even if I explicitly tell it to use the skill it is unable to, and if I ask it what skills it has available it thinks it has none.

how is the frontmatter (YAML) formatted for the SKILL.md?

I found that this, is invalid:

<img width="1284" height="291" alt="Image" src="https://github.com/user-attachments/assets/95b79e06-5c65-4581-b83c-c014278763f5" />

whereas this is valid:

<img width="1236" height="243" alt="Image" src="https://github.com/user-attachments/assets/24529f3d-9361-453a-995c-626ade276b1c" />

I made a CLI for Claude to use, (TypeScript) where you can say "Hey use pnpx claude-skills-cli to validate the skills in the project" use npx -y if you don't use pnpm it usually does an ok job of creating well structured skills to use

https://scottspence.com/posts/claude-code-skills-not-recognised

I also incorporated @otrebu's suggestion into the CLI

I was having this issue where some, but not all, skills were being recognized by Claude Code at session start. There is an undocumented (or poorly documented) 12500 character limit on metadata for ALL skills loaded by Claude Code, which can be independently confirmed through inquiry. A significant percentage of that 12500 budget is just formatting overhead you can't control. While this may not explain the reported bug in its entirety, checking for overage of this limit should be part of the debugging process. Hope that helps someone out there.

Update: the metadata character limit appears to be lower than I initially estimated and appears to be closer to 12500. After addressing this issue, I still am unable to have skills be recognized at session start without explicitly telling Claude to use skills, and so I consider this still a open bug that is open as that runs against the stated documented behavior. Combined with the windows bug (tracked elesewhere) that prevents automatically injecting such a command, this is quite frustrating.

I got it fixed for me, my skills are now properly recognized when installed via my marketplace. Maybe due to meta information changes in skill/marketplace or updates in claude code CLI. Claude Desktop is also happy with them.

So no more issues for me and my skills with Claude Code or Claude Desktop.

Latest version have no issues, the Meta format is important.

Definitely still broken on the latest - v2.0.36

I am also facing this issue; it is not clear why CC cannot discover skills. Right now, an inconsistent behavior I can detect is about the nested structure. To me, right now, it seems due to the nested structure, but according to the offical document, the complex skills can be groupped in the nested directories.

I am also facing this issue; it is not clear why CC cannot discover skills. Right now, an inconsistent behavior I can detect is about the nested structure. To me, right now, it seems due to the nested structure, but according to the offical document, the complex skills can be groupped in the nested directories.

Can you list them with <available_skills> in Claude Code?

See: https://github.com/anthropics/claude-code/issues/9716#issuecomment-3487826132

No, the answer in that blog post is not the problem, for me at least.

Maybe claude DO NOT KNOW whats skills yet. When I put some instructions about skills (eg: when to use xxx skills) in ~/.claude/CLAUDE.md then it will use the skills.

Maybe claude DO NOT KNOW whats skills yet. When I put some instructions about skills (eg: when to use xxx skills) in ~/.claude/CLAUDE.md then it will use the skills.

This is not a foolproof solution. I have done extensive cross referencing of skills, agents, and claude.md files and nothing seems to help Claude maintain or navigate the context available to it consistently -- which goes directly against all the marketing and spin around ALL of these features. God help you if he auto-compacts. In fact, an unrelated problem to this bug report is my pet peeve that Claude never wants to actually do the things instructed in .claude/CLAUDE.md.

It seems that Anthropics has been able to create ideas for managing context faster than making any of them actually work except in the most limited of minor context navigation tasks --- in which case why bother setting up any agent, skill, or claude.md documentation in the first place? It's beyond aggravating.

With over 300+ simulated tests and around 100+ manual tests I found the most reliable way to activate skills is with a forced evaluation hook

https://scottspence.com/posts/how-to-make-claude-code-skills-activate-reliably

I've added the hooks to the Claude Skills CLI use the following or ask Claude Code to add them:

# Default: forced-eval hook (84% success), global scope
pnpx claude-skills-cli add-hook

# Specify hook type and scope
pnpx claude-skills-cli add-hook --type llm-eval          # LLM eval, global
pnpx claude-skills-cli add-hook --type forced-eval --project   # Forced eval, project
pnpx claude-skills-cli add-hook --type simple-script --local   # Simple script, local

> I am also facing this issue; it is not clear why CC cannot discover skills. Right now, an inconsistent behavior I can detect is about the nested structure. To me, right now, it seems due to the nested structure, but according to the offical document, the complex skills can be groupped in the nested directories. Can you list them with <available_skills> in Claude Code? See: #9716 (comment)

The <available_skills> is empty, so this is the issue of the CLI that it cannot discover skills under nested directory, moved my skills to the top level at .claude/skills works.

<img width="1103" height="176" alt="Image" src="https://github.com/user-attachments/assets/abac0735-b8d5-497e-9086-a185d2bf1449" />

It turns out that skills don't show up with slash commands like regular commands too. SO, you have two options. In ~/.claude/commands/ you can add:
1) symlinks to the skills, e.g. ln -s ~/.claude/plugins/marketplaces/anthropic-agent-skills/document-skills/xlsx ~/.claude/skills/xlsx
2) Do what obra/superpowers does and create commands that just say, "Use the writing-plans skill exactly as written"

REF: https://github.com/anthropics/claude-code/issues/9710

People are talking about a bunch of workarounds here, but I really want to point out how messed up this is on a fundamental level.

On the skills documentation page I see this text:

Enable Skills in Settings. For Team and Enterprise users, admins must first enable Skills organization-wide.

I've done this:

<img width="707" height="1137" alt="Image" src="https://github.com/user-attachments/assets/25b9737a-b59e-4380-95dd-134bed31e14f" />

Creating skills is simple. The "skill-creator" skill provides interactive guidance: Claude asks about your workflow, generates the folder structure, formats the SKILL.md file, and bundles the resources you need. No manual file editing required.

Here's what I see when I try to actually use this:

> what skills are available?

● Currently, there are no skills available in this session. The skills system allows for specialized capabilities to
   be loaded (like PDF processing, Excel handling, etc.), but none are configured in your current environment.

  If you need specific functionality that might be available through skills, you can check the Claude Code
  documentation or let me know what you're trying to accomplish, and I can help you either:
  1. Use the available tools directly (Bash, Read, Edit, Grep, etc.)
  2. Guide you on how to set up relevant skills if needed

  Is there a specific task you're trying to accomplish that you thought might require a skill?

> Do you not have access to the skill-creator skill?

● You're right to ask! Looking at my available skills list, it appears to be empty - I don't currently have access
  to the skill-creator skill or any other skills in this session.

  This could mean:
  1. Skills need to be installed/configured in your Claude Code setup
  2. There might be a configuration issue
  3. Skills may need to be enabled

  Would you like me to look up information about how to set up and use skills in Claude Code? I can use the
  documentation to find out how to enable the skill-creator skill and other available skills.

Now the funny part of this is that I _have_ used the skill creator in the past to create a skill which Claude is now completely unaware of. Presumably Claude would have put this new skill in the correct location and format. This is far beyond a symlinking or markdown formatting issue (though I understand why people are trying to find workarounds). The basic product functionality is broken.

It's been a month and this is still not working as advertised.

Skill discovery at the project level seems most consistent.

But global skill discovery does nothing for me, i.e. ~/.claude/skills/my-skill/SKILL.md is not discoverable at all despite file naming, description content or valid yaml front-matter formatting.

Claude's own analysis was that I should either duplicate common skills across all my projects, or file a bug report.

The bug report just seems to go undiscovered too...

@dellis23 @JacksonBates oh yeah, one day after Agent skills is released and one month passed, we haven't heard any feedback yet for this basic issue.

And just to add a note here, the agent skill discovery is also not working at the project level for the nested directory as their document-skills structure.

@dellis23 this is for Claude Code, looks like you're in Claude Desktop

The <available_skills> is empty, so this is the issue of the CLI that it cannot discover skills under nested directory, moved my skills to the top level at .claude/skills works.

Ahhh! Yeah, I came across this when using the SDK, what's your project cwd set as? It goes from the root, so check that, also, the description: is it on one continuous line (not breaking YAML rules?) so:

---
name: research
description: Research topics by verifying actual source content. Use when asked to research or study links and documentation.
---

and not

---
name: research
description: 
	Research topics by verifying actual source content. Use when asked to research or study links and documentation.
---

Maybe not directly related to this issue, but I had similar issues - skills were not loaded in my project folder. I then copied all skill folders into ~.claude/ folder and suddenly Claude was able to use all skills. I'm using Claude with VScode terminal.

• I deleted skills from ~.claude/ folder
• put all skills back to project folder
• killed all Claude sessions from my terminals
• restarted VScode

...and BOOM! All skills are available.

By the way, I figured out what was wrong here for me. The docs that referenced the skill creator skill indeed have nothing to do with claude code. The web interface to upload skills also has nothing to do with it. When I asked claude to use the skill creator skill to create a skill for something, it went ahead and made a "skill" in the wrong format with the wrong directory structure -- but just close enough to be misleading (i.e. it made a pico CSS "skill" in .claude/skills/pico-css.md). It didn't seem to understand its own skill format, placement, or that it didn't have access to that skill.

When I tried to use this skill, it "worked" for a while when I explicitly called it out, probably because claude just did a glob search for it and then loaded it into context. It was only later when I tried to add another skill and get it to list its available skills that it became apparent something was wrong.

It seems that Claude code currently has a very shallow understanding of skills, which is bad news for those who hope to use skills. It cannot accurately follow the descriptions (trigger words) of skills to work stably, which is truly terrible.

same issue

This issue severely limits the usefulness of Claude Code and has wasted a lot of my time jumping through hoops trying to get it working before I came across this issue to find that the feature simply does not work months after roll-out.

"Looking at the <available_skills> section in my context, it's empty - no skills are currently available."

Eh, I thought I figured it out, but no, they still don't work. Even though my skills are in the available_skills section, here's what claude code has to say about them:

Why the skills didn't catch it: I simply didn't use them. The skills are documentation that I
need to actively consult -- they don't run automatically

@dellis23 if you explicitly ask Claude to use the skill, will it?

@dellis23 if you explicitly ask Claude to use the skill, will it?

Probably but I'm not sure how that would differ from just having it read random files with instructions in them. I thought the whole point of skills were that they were invoked automatically in the right context.

I found an inode INT overflow bug which may be related. impacts NFS or anything that has large inodes that don't fit in INT
https://github.com/anthropics/claude-code/issues/16095

Still not work at all.

Complete debug log:

2026-01-19T08:05:26.146Z [ERROR] Failed to save config with lock: Error: ENOENT: no such file or directory, lstat '/home/user/.claude.json'
2026-01-19T08:05:26.147Z [DEBUG] Writing to temp file: /home/user/.claude.json.tmp.384.1768809926147
2026-01-19T08:05:26.147Z [DEBUG] Setting permissions for new file: 600
2026-01-19T08:05:26.148Z [DEBUG] Temp file written successfully, size: 50 bytes
2026-01-19T08:05:26.148Z [DEBUG] Renaming /home/user/.claude.json.tmp.384.1768809926147 to /home/user/.claude.json
2026-01-19T08:05:26.148Z [DEBUG] File /home/user/.claude.json written atomically
2026-01-19T08:05:26.148Z [DEBUG] [init] configureGlobalMTLS starting
2026-01-19T08:05:26.149Z [DEBUG] [init] configureGlobalMTLS complete
2026-01-19T08:05:26.149Z [DEBUG] [init] configureGlobalAgents starting
2026-01-19T08:05:26.149Z [DEBUG] [init] configureGlobalAgents complete
2026-01-19T08:05:26.210Z [DEBUG] Writing to temp file: /home/user/.claude.json.tmp.384.1768809926210
2026-01-19T08:05:26.210Z [DEBUG] Preserving file permissions: 100600
2026-01-19T08:05:26.263Z [DEBUG] Temp file written successfully, size: 87 bytes
2026-01-19T08:05:26.263Z [DEBUG] Applied original permissions to temp file
2026-01-19T08:05:26.263Z [DEBUG] Renaming /home/user/.claude.json.tmp.384.1768809926210 to /home/user/.claude.json
2026-01-19T08:05:26.263Z [DEBUG] File /home/user/.claude.json written atomically
2026-01-19T08:05:26.265Z [DEBUG] Writing to temp file: /home/user/.claude.json.tmp.384.1768809926265
2026-01-19T08:05:26.265Z [DEBUG] Preserving file permissions: 100600
2026-01-19T08:05:26.265Z [DEBUG] Temp file written successfully, size: 122 bytes
2026-01-19T08:05:26.265Z [DEBUG] Applied original permissions to temp file
2026-01-19T08:05:26.265Z [DEBUG] Renaming /home/user/.claude.json.tmp.384.1768809926265 to /home/user/.claude.json
2026-01-19T08:05:26.266Z [DEBUG] File /home/user/.claude.json written atomically
2026-01-19T08:05:26.267Z [DEBUG] Writing to temp file: /home/user/.claude.json.tmp.384.1768809926267
2026-01-19T08:05:26.267Z [DEBUG] Preserving file permissions: 100600
2026-01-19T08:05:26.267Z [DEBUG] Temp file written successfully, size: 158 bytes
2026-01-19T08:05:26.267Z [DEBUG] Applied original permissions to temp file
2026-01-19T08:05:26.267Z [DEBUG] Renaming /home/user/.claude.json.tmp.384.1768809926267 to /home/user/.claude.json
2026-01-19T08:05:26.267Z [DEBUG] File /home/user/.claude.json written atomically
2026-01-19T08:05:26.273Z [DEBUG] Writing to temp file: /home/user/.claude.json.tmp.384.1768809926273
2026-01-19T08:05:26.273Z [DEBUG] Preserving file permissions: 100600
2026-01-19T08:05:26.273Z [DEBUG] Temp file written successfully, size: 195 bytes
2026-01-19T08:05:26.273Z [DEBUG] Applied original permissions to temp file
2026-01-19T08:05:26.273Z [DEBUG] Renaming /home/user/.claude.json.tmp.384.1768809926273 to /home/user/.claude.json
2026-01-19T08:05:26.273Z [DEBUG] File /home/user/.claude.json written atomically
2026-01-19T08:05:26.326Z [DEBUG] [LSP MANAGER] initializeLspServerManager() called
2026-01-19T08:05:26.326Z [DEBUG] [LSP MANAGER] Created manager instance, state=pending
2026-01-19T08:05:26.326Z [DEBUG] [LSP MANAGER] Starting async initialization (generation 1)
2026-01-19T08:05:26.328Z [DEBUG] [STARTUP] Loading MCP configs...
2026-01-19T08:05:26.329Z [DEBUG] Found 0 plugins (0 enabled, 0 disabled)
2026-01-19T08:05:26.329Z [DEBUG] Total LSP servers loaded: 0
2026-01-19T08:05:26.329Z [DEBUG] [LSP SERVER MANAGER] getAllLspServers returned 0 server(s)
2026-01-19T08:05:26.329Z [DEBUG] LSP manager initialized with 0 servers
2026-01-19T08:05:26.329Z [DEBUG] LSP server manager initialized successfully
2026-01-19T08:05:26.329Z [DEBUG] LSP notification handlers registered successfully for all 0 server(s)
2026-01-19T08:05:26.329Z [DEBUG] [STARTUP] MCP configs loaded in 1ms
2026-01-19T08:05:26.335Z [DEBUG] [STARTUP] Running setup()...
2026-01-19T08:05:26.707Z [DEBUG] Loading skills from: managed=/etc/claude-code/.claude/skills, user=/home/user/.claude/skills, project=[]
2026-01-19T08:05:27.054Z [DEBUG] installed_plugins.json doesn't exist, returning empty V2 object
2026-01-19T08:05:27.067Z [DEBUG] Error log sink initialized
2026-01-19T08:05:27.069Z [DEBUG] Writing to temp file: /home/user/.claude/todos/c752106f-6e20-4200-8204-328250603f79-agent-c752106f-6e20-4200-8204-328250603f79.json.tmp.384.1768809927069
2026-01-19T08:05:27.069Z [DEBUG] Temp file written successfully, size: 2 bytes
2026-01-19T08:05:27.069Z [DEBUG] Renaming /home/user/.claude/todos/c752106f-6e20-4200-8204-328250603f79-agent-c752106f-6e20-4200-8204-328250603f79.json.tmp.384.1768809927069 to /home/user/.claude/todos/c752106f-6e20-4200-8204-328250603f79-agent-c752106f-6e20-4200-8204-328250603f79.json
2026-01-19T08:05:27.069Z [DEBUG] File /home/user/.claude/todos/c752106f-6e20-4200-8204-328250603f79-agent-c752106f-6e20-4200-8204-328250603f79.json written atomically
2026-01-19T08:05:27.071Z [DEBUG] getPluginSkills: Processing 0 enabled plugins
2026-01-19T08:05:27.071Z [DEBUG] Total plugin skills loaded: 0
2026-01-19T08:05:27.071Z [DEBUG] Total plugin commands loaded: 0
2026-01-19T08:05:27.071Z [DEBUG] Registered 0 hooks from 0 plugins
2026-01-19T08:05:28.060Z [DEBUG] [STARTUP] setup() completed in 1725ms
2026-01-19T08:05:28.060Z [DEBUG] [STARTUP] Loading commands and agents...
2026-01-19T08:05:28.061Z [DEBUG] Total plugin agents loaded: 0
2026-01-19T08:05:28.062Z [DEBUG] Loaded 12 unique skills (managed: 0, user: 12, project: 0, legacy commands: 0)
2026-01-19T08:05:28.062Z [DEBUG] getSkills returning: 12 skill dir commands, 0 plugin skills, 0 bundled skills
2026-01-19T08:05:28.065Z [DEBUG] [STARTUP] Commands and agents loaded in 3ms
2026-01-19T08:05:28.072Z [DEBUG] Initialized versioned plugins system with 0 plugins
2026-01-19T08:05:28.075Z [DEBUG] Writing to temp file: /home/user/.claude.json.tmp.384.1768809928075
2026-01-19T08:05:28.075Z [DEBUG] Preserving file permissions: 100600
2026-01-19T08:05:28.142Z [DEBUG] Temp file written successfully, size: 263 bytes
2026-01-19T08:05:28.142Z [DEBUG] Applied original permissions to temp file
2026-01-19T08:05:28.142Z [DEBUG] Renaming /home/user/.claude.json.tmp.384.1768809928075 to /home/user/.claude.json
2026-01-19T08:05:28.142Z [DEBUG] File /home/user/.claude.json written atomically
2026-01-19T08:05:28.378Z [DEBUG] Getting matching hook commands for SessionStart with query: startup
2026-01-19T08:05:28.378Z [DEBUG] Found 0 hook matchers in settings
2026-01-19T08:05:28.378Z [DEBUG] Matched 0 unique hooks for query "startup" (0 before deduplication)
2026-01-19T08:05:28.620Z [DEBUG] Total plugin output styles loaded: 0
2026-01-19T08:05:28.708Z [DEBUG] Remote settings: Retry 1/5 after 529.7040909964718ms
2026-01-19T08:05:28.714Z [DEBUG] Ripgrep first use test: PASSED (mode=system, path=rg)
2026-01-19T08:05:28.718Z [DEBUG] LSP Diagnostics: getLSPDiagnosticAttachments called
2026-01-19T08:05:28.718Z [DEBUG] LSP Diagnostics: Checking registry - 0 pending
2026-01-19T08:05:28.718Z [DEBUG] Hooks: Found 0 total hooks in registry
2026-01-19T08:05:28.718Z [DEBUG] Hooks: checkForNewResponses returning 0 responses
2026-01-19T08:05:28.722Z [DEBUG] Getting matching hook commands for UserPromptSubmit with query: undefined
2026-01-19T08:05:28.722Z [DEBUG] Found 0 hook matchers in settings
2026-01-19T08:05:28.722Z [DEBUG] Matched 0 unique hooks for query "no match query" (0 before deduplication)
2026-01-19T08:05:28.730Z [DEBUG] Auto tool search disabled: 0 chars (threshold: 50000, 10% of context)
2026-01-19T08:05:28.736Z [DEBUG] Skills and commands included in Skill tool: calendar, chatgpt-core, crypto, feature-planning, frontend-design, nano banana, news-aggregation, sora-video, stock, tts, weather, web-development
2026-01-19T08:05:28.741Z [DEBUG] [API:request] Creating client, ANTHROPIC_CUSTOM_HEADERS present: true, has Authorization header: false
2026-01-19T08:05:28.741Z [DEBUG] [API:auth] OAuth token check starting
2026-01-19T08:05:28.741Z [DEBUG] [API:auth] OAuth token check complete
2026-01-19T08:05:28.791Z [DEBUG] Writing to temp file: /home/user/.claude.json.tmp.384.1768809928791
2026-01-19T08:05:28.791Z [DEBUG] Preserving file permissions: 100600
2026-01-19T08:05:28.791Z [DEBUG] Temp file written successfully, size: 343 bytes
2026-01-19T08:05:28.791Z [DEBUG] Applied original permissions to temp file
2026-01-19T08:05:28.791Z [DEBUG] Renaming /home/user/.claude.json.tmp.384.1768809928791 to /home/user/.claude.json
2026-01-19T08:05:28.791Z [DEBUG] File /home/user/.claude.json written atomically
2026-01-19T08:05:28.810Z [DEBUG] Watching for changes in skill/command directories: /home/user/.claude/skills...
2026-01-19T08:05:29.424Z [DEBUG] Remote settings: No settings found (404)
2026-01-19T08:05:29.424Z [DEBUG] Programmatic settings change notification for policySettings
2026-01-19T08:05:29.424Z [DEBUG] Plugin hooks: reloading due to policySettings change
2026-01-19T08:05:29.425Z [DEBUG] Found 0 plugins (0 enabled, 0 disabled)
2026-01-19T08:05:29.426Z [DEBUG] [Perfetto] initializePerfettoTracing called, env value: undefined
2026-01-19T08:05:29.428Z [DEBUG] Registered 0 hooks from 0 plugins
2026-01-19T08:05:31.163Z [DEBUG] Stream started - received first chunk
2026-01-19T08:05:32.820Z [DEBUG] executePreToolHooks called for tool: Skill
2026-01-19T08:05:32.820Z [DEBUG] Getting matching hook commands for PreToolUse with query: Skill
2026-01-19T08:05:32.820Z [DEBUG] Found 0 hook matchers in settings
2026-01-19T08:05:32.820Z [DEBUG] Matched 0 unique hooks for query "Skill" (0 before deduplication)
2026-01-19T08:05:32.822Z [DEBUG] "Permission suggestions for Skill: [\n  {\n    \"type\": \"addRules\",\n    \"rules\": [\n      {\n        \"toolName\": \"Skill\",\n        \"ruleContent\": \"feature-planning\"\n      }\n    ],\n    \"behavior\": \"allow\",\n    \"destination\": \"localSettings\"\n  },\n  {\n    \"type\": \"addRules\",\n    \"rules\": [\n      {\n        \"toolName\": \"Skill\",\n        \"ruleContent\": \"feature-planning:*\"\n      }\n    ],\n    \"behavior\": \"allow\",\n    \"destination\": \"localSettings\"\n  }\n]"
2026-01-19T08:05:32.833Z [DEBUG] LSP Diagnostics: getLSPDiagnosticAttachments called
2026-01-19T08:05:32.833Z [DEBUG] LSP Diagnostics: Checking registry - 0 pending
2026-01-19T08:05:32.833Z [DEBUG] Hooks: Found 0 total hooks in registry
2026-01-19T08:05:32.833Z [DEBUG] Hooks: checkForNewResponses returning 0 responses
2026-01-19T08:05:32.834Z [DEBUG] Auto tool search disabled: 0 chars (threshold: 50000, 10% of context)
2026-01-19T08:05:32.838Z [DEBUG] [API:request] Creating client, ANTHROPIC_CUSTOM_HEADERS present: true, has Authorization header: false
2026-01-19T08:05:32.838Z [DEBUG] [API:auth] OAuth token check starting
2026-01-19T08:05:32.838Z [DEBUG] [API:auth] OAuth token check complete
2026-01-19T08:05:34.639Z [DEBUG] Stream started - received first chunk
2026-01-19T08:05:44.745Z [DEBUG] executePreToolHooks called for tool: AskUserQuestion
2026-01-19T08:05:44.746Z [DEBUG] Getting matching hook commands for PreToolUse with query: AskUserQuestion
2026-01-19T08:05:44.746Z [DEBUG] Found 0 hook matchers in settings
2026-01-19T08:05:44.746Z [DEBUG] Matched 0 unique hooks for query "AskUserQuestion" (0 before deduplication)
2026-01-19T08:05:44.759Z [DEBUG] LSP Diagnostics: getLSPDiagnosticAttachments called
2026-01-19T08:05:44.759Z [DEBUG] LSP Diagnostics: Checking registry - 0 pending
2026-01-19T08:05:44.759Z [DEBUG] Hooks: Found 0 total hooks in registry
2026-01-19T08:05:44.759Z [DEBUG] Hooks: checkForNewResponses returning 0 responses
2026-01-19T08:05:44.760Z [DEBUG] Auto tool search disabled: 0 chars (threshold: 50000, 10% of context)
2026-01-19T08:05:44.766Z [DEBUG] [API:request] Creating client, ANTHROPIC_CUSTOM_HEADERS present: true, has Authorization header: false
2026-01-19T08:05:44.766Z [DEBUG] [API:auth] OAuth token check starting
2026-01-19T08:05:44.766Z [DEBUG] [API:auth] OAuth token check complete
2026-01-19T08:05:46.478Z [DEBUG] Stream started - received first chunk
2026-01-19T08:05:48.152Z [DEBUG] Getting matching hook commands for Stop with query: undefined
2026-01-19T08:05:48.152Z [DEBUG] Found 0 hook matchers in settings
2026-01-19T08:05:48.152Z [DEBUG] Matched 0 unique hooks for query "no match query" (0 before deduplication)
2026-01-19T08:05:48.154Z [DEBUG] Getting matching hook commands for SessionEnd with query: other
2026-01-19T08:05:48.154Z [DEBUG] Found 0 hook matchers in settings
2026-01-19T08:05:48.154Z [DEBUG] Matched 0 unique hooks for query "other" (0 before deduplication)

As you see, skills were already loaded:

2026-01-19T08:05:28.062Z [DEBUG] Loaded 12 unique skills (managed: 0, user: 12, project: 0, legacy commands: 0)
2026-01-19T08:05:28.062Z [DEBUG] getSkills returning: 12 skill dir commands, 0 plugin skills, 0 bundled skills

But the requested skill feature-planning wasn't executed:

2026-01-19T08:05:32.820Z [DEBUG] executePreToolHooks called for tool: Skill
2026-01-19T08:05:32.820Z [DEBUG] Getting matching hook commands for PreToolUse with query: Skill
2026-01-19T08:05:32.820Z [DEBUG] Found 0 hook matchers in settings
2026-01-19T08:05:32.820Z [DEBUG] Matched 0 unique hooks for query "Skill" (0 before deduplication)
2026-01-19T08:05:32.822Z [DEBUG] "Permission suggestions for Skill: [\n  {\n    \"type\": \"addRules\",\n    \"rules\": [\n      {\n        \"toolName\": \"Skill\",\n        \"ruleContent\": \"feature-planning\"\n      }\n    ],\n    \"behavior\": \"allow\",\n    \"destination\": \"localSettings\"\n  },\n  {\n    \"type\": \"addRules\",\n    \"rules\": [\n      {\n        \"toolName\": \"Skill\",\n        \"ruleContent\": \"feature-planning:*\"\n      }\n    ],\n    \"behavior\": \"allow\",\n    \"destination\": \"localSettings\"\n  }\n]"
2026-01-19T08:05:32.833Z [DEBUG] LSP Diagnostics: getLSPDiagnosticAttachments called
2026-01-19T08:05:32.833Z [DEBUG] LSP Diagnostics: Checking registry - 0 pending
2026-01-19T08:05:32.833Z [DEBUG] Hooks: Found 0 total hooks in registry
2026-01-19T08:05:32.833Z [DEBUG] Hooks: checkForNewResponses returning 0 responses
2026-01-19T08:05:32.834Z [DEBUG] Auto tool search disabled: 0 chars (threshold: 50000, 10% of context)

Related Issue: Skill Tool Recognition (#19212)

I've created a related issue #19212 that addresses a different manifestation of the same root problem.

Both Issues Matter

While this issue (#9716) focuses on the assistant not proactively suggesting skills, my issue (#19212) focuses on the Skill() tool not recognizing local skills at all.

Why Both Should Be Fixed

| Issue | Manifestation | Impact |
|-------|---------------|--------|
| #9716 (this one) | Assistant doesn't know about skills | Skills must be manually invoked |
| #19212 | Skill("name") fails with "Unknown skill" | Programmatic skill invocation broken |

The Complete Solution

For a truly functional local skills system, both issues need to be addressed:

1. #9716 - Inject local skills into <available_skills> context
2. #19212 - Make the Skill() tool recognize local skills

Without #9716: Skills exist but aren't suggested automatically
Without #19212: Skills can't be invoked programmatically

Request to Anthropic

Please prioritize fixing the entire local skills system, not just one manifestation. Local skills are a powerful feature for:

• Rapid skill development and testing
• Personal/team-specific workflows
• Quick iteration without plugin overhead

Thank you for considering both issues\! 🙏

Please prioritize fixing the entire local skills system

Yes please.

Skills have been advertised for months and at first it was okay they were so buggy because they were new, but months after their release I've been unable to use them even once.

I added anthropic's skill-creator skill to my project and asked Claude to create a new skill for me, it did so without activating the skill-creator skill.

With over 300+ simulated tests and around 100+ manual tests I found the most reliable way to activate skills is with a forced evaluation hook scottspence.com/posts/how-to-make-claude-code-skills-activate-reliably I've added the hooks to the Claude Skills CLI use the following or ask Claude Code to add them: # Default: forced-eval hook (84% success), global scope pnpx claude-skills-cli add-hook # Specify hook type and scope pnpx claude-skills-cli add-hook --type llm-eval # LLM eval, global pnpx claude-skills-cli add-hook --type forced-eval --project # Forced eval, project pnpx claude-skills-cli add-hook --type simple-script --local # Simple script, local

I've moved these skills to a marketplace now

https://github.com/spences10/claude-code-toolkit

Found a root cause for this on Windows: CRLF line endings break skill loading.

If your SKILL.md file has Windows line endings (\r\n), the YAML frontmatter parser fails silently and the skill won't appear in the available
skills list.

Diagnosis:
# Check your skill file
od -c ~/.claude/skills/your-skill/SKILL.md | head -5

# If you see \r\n instead of just \n, that's the problem

Fix:
# Convert to Unix line endings
tr -d '\r' < SKILL.md > SKILL.md.tmp && mv SKILL.md.tmp SKILL.md

FWIW I work exclusively on Linux and skills never have worked and still don't.

Found a root cause for this on Windows: CRLF line endings break skill loading. If your SKILL.md file has Windows line endings (\r\n), the YAML frontmatter parser fails silently and the skill won't appear in the available skills list. Diagnosis: # Check your skill file od -c ~/.claude/skills/your-skill/SKILL.md | head -5 # If you see \r\n instead of just \n, that's the problem Fix: # Convert to Unix line endings tr -d '\r' < SKILL.md > SKILL.md.tmp && mv SKILL.md.tmp SKILL.md

Funny, to me is the other way around; LF breaks things and CRLF fixes them. I'm also on Windows. Just changed on the SKILL.md. Wonder if I must change in all of the references too...

Still experiencing this issue as of 2026-02-04.

Fresh session, zero context, invoked a skill via slash command. The system provided "Base directory for this skill: /path/to/skill" but Claude did not read any files from that directory. Instead, it used only the inline instructions that happened to be in the prompt and proceeded to act on them incorrectly.

This makes skills unreliable as a product feature. Is there a timeline for a fix?

After almost five months, at minimum an acknowledgement of this problem from the team would be nice.

My experience is skills (or commands for that matter) are auto-used so rarely I don't depend on it anymore and literally have skills and commands literally mention other skills and commands by name ("Use /foo and /bar"), which I don't think works reliably either BTW.

I have skills with descriptions like "Use this when reading, writing or reviewing TypeScript code" or "TypeScript programming and code review guidelines" and they still won't trigger when working with TypeScript.

My workaround is that I tell the LLM to explicitly use the whatever-skill-name.md file and then it searches around the repo blindly for it and eventually complies. It's not the worst but it's not good and it's certainly not a feature at that point.

getting this issue, file naming, explicitly asking to use skill often doesnt work

my problem is instead of this, is that claude code not aware that there are skills already installed in ~/.agents folder, which should be the universal folder where agent look for skills, right? instead i had to put skills inside ~/.claude, ~/.gemini, and so on.

Claude doesn't obey .agents or AGENTS.md.

I found that using /insights Claude suggested a skill creation command and using that exact command creates a skill that was recognized.

There's nothing obviously special about this approach, but I'll share it here in case it might help someone:

mkdir -p .claude/skills/commit && cat > .claude/skills/commit/SKILL.md << 'EOF'
# Commit Skill
1. Run `git diff --stat` and `git status` to see ALL changes
2. Group related changes into logical commits
3. NEVER leave uncommitted files without explicitly listing them and explaining why
4. After committing, run `git status` again and report any remaining changes
5. Use conventional commit messages (fix:, feat:, refactor:, test:)
EOF

After 7 months of running 112 skills in production (building an API platform with zero engineering background), here's what actually works and what doesn't:

What makes skills trigger reliably:

1. alwaysApply: true in YAML frontmatter — This is the most reliable way. Skills with alwaysApply: true get injected into every conversation. The downside is context bloat, so only use it for your most critical skills.

1. Descriptive description field — The matching seems to use the description, not just the filename. "Fix Docker OOM kills on small VPS" triggers much more reliably than "Docker deployment".

1. "Use when:" section at the top — After the YAML frontmatter, start with explicit trigger conditions:

``
Use when: (1) Docker build fails with OOM, (2) VPS has < 4GB RAM, (3) deployment takes > 10 minutes
``

1. Specific filenames — docker-small-vps-deploy-optimization.md triggers better than docker-tips.md.

What doesn't work:

• Generic descriptions like "coding best practices"
• Skills that are too long (>500 lines seem to get ignored more often)
• Expecting Claude to auto-discover skills without any hint in your prompt

Our workaround for critical skills:
We add a line in CLAUDE.md that references important skills explicitly:

When debugging Docker issues, use the skill: docker-small-vps-deploy-optimization

This acts as a bridge — CLAUDE.md is always read, and it points Claude to the right skill.

Reference: We open-sourced all 112 skills at washin-claude-skills. You can install them all with curl -sSL https://raw.githubusercontent.com/sstklen/washin-claude-skills/main/install.sh | bash and study the format that works. Each skill was extracted from a real production bug.

The core issue is real — skill auto-triggering is unreliable. But with the right format + CLAUDE.md bridging, we get ~80% hit rate in production.

I've shared info in this thread and no one seams to care read it, at this point it's just shouting into the void lol!

I've shared info in this thread and no one seams to care read it, at this point it's just shouting into the void lol!

Scott, I've personally seen your blog posted a few times around here, and I've looked at it, and it wasn't related to the issue I was having. I'm guessing people are seeing it and coming to a similar conclusion and are moving on to trying other things.

Skills need specific structure to be recognized. Common issues:

1. File must be named SKILL.md (case-sensitive), not skill.md:

.claude/skills/shadcn-components/SKILL.md  ✅
.claude/skills/shadcn-components/skill.md  ❌ (won't be found)

2. Frontmatter must include name and description:

---
name: shadcn-components
description: Install and configure shadcn/ui components
user-invocable: true
---

Instructions here...

The description field is what Claude uses to match your query to the skill. Make it specific.

3. user-invocable: true enables slash-command access:
Without this, the skill can only be triggered by other skills or the system. With it, you can invoke it via /shadcn-components.

4. Skills are loaded at session start. If you add a skill mid-session, it won't be detected until you start a new session or use /clear.

5. Verify your skill is detected:
Ask Claude: "List all available skills" — it should show skills from the system-reminder that lists available skills. If your skill isn't in that list, the structure or path is wrong.

Debugging checklist:

# Verify path exists
ls -la .claude/skills/*/SKILL.md

# Verify frontmatter is valid YAML
head -10 .claude/skills/shadcn-components/SKILL.md

Same problem here — skills exist, descriptions match, Claude just ignores them and does its own thing.

I worked around it by making slash commands the entry point instead of relying on skill discovery. You type /develop-feature or /implement-slice and the pipeline runs explicitly. No hoping Claude picks the right skill.

https://github.com/Koroqe/claude-code-sdlc — built the whole workflow around explicit commands for this reason.

ran into this too. the fix for us was making the skill description in the YAML frontmatter very specific about trigger conditions. vague descriptions like 'helps with code' mean the model never matches it. we use patterns like 'Use when: user says X, Y, or Z' in the description field and that dramatically improved auto-discovery. also make sure the skill file ends in SKILL.md not just .md.

example of a skill with specific trigger descriptions that get auto-discovered reliably: https://github.com/m13v/social-autoposter/blob/main/skill/SKILL.md - the description field lists exact trigger phrases.

Concrete failure mode: local skills are invisible to the model

I have a local skill at .claude/skills/<name>/SKILL.md — a structured wizard that guides through multiple steps with AskUserQuestion prompts at each decision point.

The problem: There's no way for the model to discover or invoke local skills. They only work through the CLI-level / intercept. This breaks in several legitimate scenarios:

• Embedding a skill invocation in a longer prompt ("do X, then /my-skill Y, then Z")
• Accidental leading space before the slash command
• Expecting the model to proactively suggest a relevant skill based on the user's intent

In all these cases, the model has zero awareness that the skill exists. It handles the workflow manually — skipping all wizard questions, making silent decisions about settings that required user input, and writing files without confirmation.

The gap: Local skills appear in autocomplete and work when invoked via direct / prefix, but they're absent from the system-reminder skills list and inaccessible to the Skill tool. There is no fallback path.

Expected: Local skills from .claude/skills/ should appear in the system-reminder skills list alongside plugin skills, so the model can invoke them via the Skill tool.

Claude Code 2.1.100 on WSL2, using .claude/skills/ with disable-model-invocation: true.

For the subset of this where the skill is discoverable but just not chosen — like @ajax-semenov-y's case above, where "what skills do you have?" lists it yet a matching task request still falls back to generic tools — a standing instruction has helped me more than tuning each skill's description.

I moved the routine into a CLAUDE.md instead of relying only on per-skill triggers: analyze the request → review the available skills → use the relevant ones → then act, and skip that for trivial chat so it doesn't burn tokens. Because it loads as global context every session, it competes for salience on more even footing with the other rules in CLAUDE.md — which, as @JacksonBates noted, can otherwise quietly outrank a skill trigger.

Honest scope: this only helps when the skill is actually present in context. It does nothing for the other failure mode in this thread — local .claude/skills/ not appearing in <available_skills> at all — that's a real loading bug a CLAUDE.md can't reach.

MIT, no dependencies: https://github.com/blackstardigitalstudio/claude-auto-skills