[Bug]: Claude skill discovery drops skills with frontmatter Claude Code itself accepts (strict YAML vs CLI leniency), silently

[tarunguptain]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Install a skill whose description is a plain scalar containing a colon followed by a space. Real-world example: LambdaTest's kane-cli installer (kane-cli install skill) writes ~/.claude/skills/kane-cli/SKILL.md with:

   ---
   name: kane-cli
   description: Browser automation + AI test authoring via kane-cli: run browser objectives, ...
   ---

   yaml.parse rejects this (mapping values are not allowed here), but Claude Code's own frontmatter parser accepts it — the skill loads and works in every Claude Code session.

2. Start the desktop app with a Claude provider instance and wait for a capability probe cycle.

3. Type $ in the composer, or read ~/.t3/caches/claudeAgent.json.

Expected behavior

Whatever file the Claude Code CLI loads as a skill should be discovered by T3's own scanner too — the CLI is the authority on what it accepts. Failing that, dropping a skill should at least log which file was rejected and why.

Actual behavior

parseSkillFrontmatter in apps/server/src/provider/Drivers/ClaudeSkills.ts strict-YAML-parses the frontmatter and skips the entry as malformed with no log. The same cache snapshot shows the contradiction: the skill appears in slashCommands (enumerated by the Claude Code SDK probe, which accepts the file) while skills is [] (T3's scanner dropped it). If it is the user's only skill, the $ picker is empty and nothing explains why.

Related but distinct: #6449 covers discovery scanning the wrong directory (ServerConfig.cwd), and #1084 covers malformed-skill diagnostics in threads. This one is the parser-strictness mismatch: a skill that demonstrably works in Claude Code is invisible in T3.

Impact

Minor bug or occasional failure

Version or commit

Desktop 0.0.33 (alpha); code path unchanged at main HEAD

Environment

macOS (Darwin 25.5.0), T3 Code (Alpha) 0.0.33, Claude Code CLI 2.1.237, kane-cli skill 0.0.17 as shipped by @testmuai/kane-cli-skill

Logs or stack traces

# ~/.t3/caches/claudeAgent.json (one snapshot, provider ready, authenticated)
"slashCommands": [... "kane-cli" ...]   # SDK probe accepted the file
"skills": []                            # T3's scanner dropped it, no log emitted

# python yaml.safe_load on the same frontmatter:
mapping values are not allowed here, line 2, column 65

Workaround

Quote the description in the skill's frontmatter so it parses as strict YAML. Works, but every consumer of an installer-shipped skill has to know to do it, and nothing tells them.

---

Investigated and filed by Claude Fable 5 (claude-fable-5) on behalf of the repo user; findings verified against the packaged app bundle and source at main.

[0xFFord]

A second real-world example, still present on T3 Code (Alpha) 0.0.36, macOS 26.5.2, claude CLI 2.1.251.

~/.claude/skills/codex-computer-use/SKILL.md:

---
name: codex-computer-use
description: Drive or read a real Mac app — click, type, screenshot, check what's on screen. Also verify something actually runs end to end: hit the endpoint, drive a headless browser, exercise the flow in a simulator.
---

The colon-space is inside end to end: hit the endpoint. Claude Code loads this skill in every session; T3's parseSkillFrontmatter calls it malformed and does continue.

What makes it easy to spot from the UI alone is the asymmetry you describe, visible side by side in one app:

• Type / — /codex-computer-use is listed, because it comes through capabilities.slashCommands from the SDK probe, which accepts the file.
• Type $ — the row is gone. The list jumps straight from Chrome Extensions to Codex Implementation.

Same skill, same app, same second. And in the cache: 46 directories with a SKILL.md under ~/.claude/skills, 44 entries in skills.

There is no log line, no badge and no count discrepancy shown anywhere in the UI, so the only way to notice is to know the skill should be there and go looking. Agreeing with your "failing that, log which file was rejected and why" — even a single warning naming the path would have made this a two-minute diagnosis instead of a bisect.