disable-model-invocation skills silently unavailable when skills-dashboard GrowthBook flag is off

Description

Skills with disable-model-invocation: true in their SKILL.md frontmatter (personal skills under $CLAUDE_CONFIG_DIR/skills/, aka "user-only"/manually-invoked skills) are completely absent from every list the model receives — not just excluded from auto-invocation as intended, but invisible even when the user explicitly types /skill-name. There is no error message pointing at the actual cause.

Environment

• Claude Code version: 2.1.210 (native install)
• OS: macOS (darwin)
• CLAUDE_CONFIG_DIR correctly set and verified pointing at the right directory
• Personal skills installed as valid symlinks under $CLAUDE_CONFIG_DIR/skills/* → real directories, each with a well-formed SKILL.md (valid YAML frontmatter, disable-model-invocation: true)

Repro

1. Have a personal skill at $CLAUDE_CONFIG_DIR/skills/<name>/SKILL.md with disable-model-invocation: true in frontmatter.
2. Start a fresh Claude Code session.
3. Type /<name> (or ask Claude to invoke that skill by name).

Expected: Per the docs, disable-model-invocation: true only prevents Claude from auto-invoking the skill — the user should still be able to manually invoke it via slash command.

Actual: Claude reports the skill "is not in the available skills list" / doesn't exist, as if the file weren't there at all. This happened for 17 of 48 personal skills in one real setup, all skills that had disable-model-invocation: true set — while skills without that flag loaded fine.

Root cause (found via manual investigation)

~/.config/claude/.claude.json → cachedGrowthBookFeatures contains:

"claude_code_skills_dashboard_enabled_cli": false,
"tengu_skills_dashboard_enabled": false

These were freshly refetched the same day (not stale cache). It appears the "user-invocable skills" list — the separate index the CLI is supposed to build so it can match a literal /skill-name against disable-model-invocation: true skills — is gated behind this flag. With the flag off, that list is apparently never built or never passed to the model, so those skills are 100% invisible and manual invocation silently fails, with zero indication that a feature flag is the cause.

Ask

• Either decouple manual slash-command invocation from the "skills dashboard" flag entirely (manual invocation of an existing, valid, correctly-configured skill shouldn't depend on an unrelated UI feature rollout), or
• If the gating is intentional, surface a clear error/warning when a user tries to invoke a disable-model-invocation skill while the underlying feature is flagged off, instead of a generic "skill doesn't exist" response that sends users down a filesystem/symlink debugging rabbit hole.