Skill catalog descriptions intermittently missing from system prompt (frontmatter on disk is correct)

Preflight Checklist

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

What's Wrong?

Summary

The "available skills" list injected into the system prompt at session start
sometimes omits a skill's description: entirely (rendered as a bare
- skill-name with nothing after the colon), even though the skill's
SKILL.md frontmatter on disk has a complete, valid description: field.
Since the model only sees the catalog text (not the files), this silently
breaks natural-language auto-triggering for the affected skills — they only
work when invoked by explicit name.

Environment

• Standalone Windows binary install (not npm), ~/.local/bin/claude, ~234MB,
  file dated 2026-06-27. claude --version not captured in this report —
  blocked by an unrelated local shell policy on my side; happy to supply it
  on request.
• Windows 11, skills sourced from: plain ~/.claude/skills/<name>/SKILL.md,
  plugin-provided skills (via ~/.claude/plugins/marketplaces/...), and a
  Windows junction into an external directory.

Reproduction / evidence

Across 3 separate sessions on the same machine, same ~/.claude config,
I compared each skill's description visibility in the system-prompt catalog
against its actual SKILL.md frontmatter (read directly from disk):

• 13 skills (spanning multiple unrelated sources — a plugin family, plain
  standalone skills, and a junctioned external skill) showed a blank
  description in the catalog while their on-disk frontmatter was fully
  populated and valid YAML.
• The specific set is NOT stable across sessions: ponytail and
  industrial-brutalist-ui were blank in session 1, then had full
  descriptions in session 2. minimalist-ui had a full description in
  session 1, then was blank in session 3. Most others (11/13) stayed
  consistently blank across all 3 sessions.
• Ruled out as causes: plugin enable/disable state in settings.json
  (enabledPlugins — the affected plugin was never listed there in its
  entire git history, yet worked reliably for weeks before this was
  noticed), directory type (regular dir vs. junction — both regular dirs
  and a junction appear on both sides of the working/broken split),
  YAML style (description: text single-line vs. description: > folded
  block — both styles appear on both sides), and description length (a
  skill with a very long single-line description renders fully elsewhere).
• Manually invoking an affected skill by exact name works correctly and
  returns its full, correct instructions — confirming the file itself is
  never corrupted, only the catalog's rendering of it in that session.

Impact

Any skill whose description drops out of the catalog for a given session
becomes invisible to the model's own judgment for that session — it cannot
be auto-triggered by natural language matching its stated triggers, only by
being named explicitly. This is silent (no error, no warning) and
intermittent, so it's easy to mistake for "the skill doesn't work" rather
than "the catalog lost its metadata this session."

What would help

• Any pointer to how the system-prompt skill catalog is assembled (e.g. is
  there a token/length budget that silently truncates description fields
  under certain conditions, or a caching layer that can serve a stale/empty
  entry) would let me build a tighter, deterministic repro.
• Happy to provide the exact skill list, full session transcripts (redacted
  as needed), or run additional diagnostics on request.

What Should Happen?

Summary

The "available skills" list injected into the system prompt at session start
sometimes omits a skill's description: entirely (rendered as a bare
- skill-name with nothing after the colon), even though the skill's
SKILL.md frontmatter on disk has a complete, valid description: field.
Since the model only sees the catalog text (not the files), this silently
breaks natural-language auto-triggering for the affected skills — they only
work when invoked by explicit name.

Environment

• Standalone Windows binary install (not npm), ~/.local/bin/claude, ~234MB,
  file dated 2026-06-27. claude --version not captured in this report —
  blocked by an unrelated local shell policy on my side; happy to supply it
  on request.
• Windows 11, skills sourced from: plain ~/.claude/skills/<name>/SKILL.md,
  plugin-provided skills (via ~/.claude/plugins/marketplaces/...), and a
  Windows junction into an external directory.

Reproduction / evidence

Across 3 separate sessions on the same machine, same ~/.claude config,
I compared each skill's description visibility in the system-prompt catalog
against its actual SKILL.md frontmatter (read directly from disk):

• 13 skills (spanning multiple unrelated sources — a plugin family, plain
  standalone skills, and a junctioned external skill) showed a blank
  description in the catalog while their on-disk frontmatter was fully
  populated and valid YAML.
• The specific set is NOT stable across sessions: ponytail and
  industrial-brutalist-ui were blank in session 1, then had full
  descriptions in session 2. minimalist-ui had a full description in
  session 1, then was blank in session 3. Most others (11/13) stayed
  consistently blank across all 3 sessions.
• Ruled out as causes: plugin enable/disable state in settings.json
  (enabledPlugins — the affected plugin was never listed there in its
  entire git history, yet worked reliably for weeks before this was
  noticed), directory type (regular dir vs. junction — both regular dirs
  and a junction appear on both sides of the working/broken split),
  YAML style (description: text single-line vs. description: > folded
  block — both styles appear on both sides), and description length (a
  skill with a very long single-line description renders fully elsewhere).
• Manually invoking an affected skill by exact name works correctly and
  returns its full, correct instructions — confirming the file itself is
  never corrupted, only the catalog's rendering of it in that session.

Impact

Any skill whose description drops out of the catalog for a given session
becomes invisible to the model's own judgment for that session — it cannot
be auto-triggered by natural language matching its stated triggers, only by
being named explicitly. This is silent (no error, no warning) and
intermittent, so it's easy to mistake for "the skill doesn't work" rather
than "the catalog lost its metadata this session."

What would help

• Any pointer to how the system-prompt skill catalog is assembled (e.g. is
  there a token/length budget that silently truncates description fields
  under certain conditions, or a caching layer that can serve a stale/empty
  entry) would let me build a tighter, deterministic repro.
• Happy to provide the exact skill list, full session transcripts (redacted
  as needed), or run additional diagnostics on request.

Error Messages/Logs

Steps to Reproduce

Summary

The "available skills" list injected into the system prompt at session start
sometimes omits a skill's description: entirely (rendered as a bare
- skill-name with nothing after the colon), even though the skill's
SKILL.md frontmatter on disk has a complete, valid description: field.
Since the model only sees the catalog text (not the files), this silently
breaks natural-language auto-triggering for the affected skills — they only
work when invoked by explicit name.

Environment

• Standalone Windows binary install (not npm), ~/.local/bin/claude, ~234MB,
  file dated 2026-06-27. claude --version not captured in this report —
  blocked by an unrelated local shell policy on my side; happy to supply it
  on request.
• Windows 11, skills sourced from: plain ~/.claude/skills/<name>/SKILL.md,
  plugin-provided skills (via ~/.claude/plugins/marketplaces/...), and a
  Windows junction into an external directory.

Reproduction / evidence

Across 3 separate sessions on the same machine, same ~/.claude config,
I compared each skill's description visibility in the system-prompt catalog
against its actual SKILL.md frontmatter (read directly from disk):

• 13 skills (spanning multiple unrelated sources — a plugin family, plain
  standalone skills, and a junctioned external skill) showed a blank
  description in the catalog while their on-disk frontmatter was fully
  populated and valid YAML.
• The specific set is NOT stable across sessions: ponytail and
  industrial-brutalist-ui were blank in session 1, then had full
  descriptions in session 2. minimalist-ui had a full description in
  session 1, then was blank in session 3. Most others (11/13) stayed
  consistently blank across all 3 sessions.
• Ruled out as causes: plugin enable/disable state in settings.json
  (enabledPlugins — the affected plugin was never listed there in its
  entire git history, yet worked reliably for weeks before this was
  noticed), directory type (regular dir vs. junction — both regular dirs
  and a junction appear on both sides of the working/broken split),
  YAML style (description: text single-line vs. description: > folded
  block — both styles appear on both sides), and description length (a
  skill with a very long single-line description renders fully elsewhere).
• Manually invoking an affected skill by exact name works correctly and
  returns its full, correct instructions — confirming the file itself is
  never corrupted, only the catalog's rendering of it in that session.

Impact

Any skill whose description drops out of the catalog for a given session
becomes invisible to the model's own judgment for that session — it cannot
be auto-triggered by natural language matching its stated triggers, only by
being named explicitly. This is silent (no error, no warning) and
intermittent, so it's easy to mistake for "the skill doesn't work" rather
than "the catalog lost its metadata this session."

What would help

• Any pointer to how the system-prompt skill catalog is assembled (e.g. is
  there a token/length budget that silently truncates description fields
  under certain conditions, or a caching layer that can serve a stale/empty
  entry) would let me build a tighter, deterministic repro.
• Happy to provide the exact skill list, full session transcripts (redacted
  as needed), or run additional diagnostics on request.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

1.0.123

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Summary

The "available skills" list injected into the system prompt at session start
sometimes omits a skill's description: entirely (rendered as a bare
- skill-name with nothing after the colon), even though the skill's
SKILL.md frontmatter on disk has a complete, valid description: field.
Since the model only sees the catalog text (not the files), this silently
breaks natural-language auto-triggering for the affected skills — they only
work when invoked by explicit name.

Environment

• Standalone Windows binary install (not npm), ~/.local/bin/claude, ~234MB,
  file dated 2026-06-27. claude --version not captured in this report —
  blocked by an unrelated local shell policy on my side; happy to supply it
  on request.
• Windows 11, skills sourced from: plain ~/.claude/skills/<name>/SKILL.md,
  plugin-provided skills (via ~/.claude/plugins/marketplaces/...), and a
  Windows junction into an external directory.

Reproduction / evidence

Across 3 separate sessions on the same machine, same ~/.claude config,
I compared each skill's description visibility in the system-prompt catalog
against its actual SKILL.md frontmatter (read directly from disk):

• 13 skills (spanning multiple unrelated sources — a plugin family, plain
  standalone skills, and a junctioned external skill) showed a blank
  description in the catalog while their on-disk frontmatter was fully
  populated and valid YAML.
• The specific set is NOT stable across sessions: ponytail and
  industrial-brutalist-ui were blank in session 1, then had full
  descriptions in session 2. minimalist-ui had a full description in
  session 1, then was blank in session 3. Most others (11/13) stayed
  consistently blank across all 3 sessions.
• Ruled out as causes: plugin enable/disable state in settings.json
  (enabledPlugins — the affected plugin was never listed there in its
  entire git history, yet worked reliably for weeks before this was
  noticed), directory type (regular dir vs. junction — both regular dirs
  and a junction appear on both sides of the working/broken split),
  YAML style (description: text single-line vs. description: > folded
  block — both styles appear on both sides), and description length (a
  skill with a very long single-line description renders fully elsewhere).
• Manually invoking an affected skill by exact name works correctly and
  returns its full, correct instructions — confirming the file itself is
  never corrupted, only the catalog's rendering of it in that session.

Impact

Any skill whose description drops out of the catalog for a given session
becomes invisible to the model's own judgment for that session — it cannot
be auto-triggered by natural language matching its stated triggers, only by
being named explicitly. This is silent (no error, no warning) and
intermittent, so it's easy to mistake for "the skill doesn't work" rather
than "the catalog lost its metadata this session."

What would help

• Any pointer to how the system-prompt skill catalog is assembled (e.g. is
  there a token/length budget that silently truncates description fields
  under certain conditions, or a caching layer that can serve a stale/empty
  entry) would let me build a tighter, deterministic repro.
• Happy to provide the exact skill list, full session transcripts (redacted
  as needed), or run additional diagnostics on request.

Start by reproducing the missing descriptions in the system-prompt skill catalog across sessions, comparing each entry with the corresponding SKILL.md frontmatter on disk. Investigate the catalog assembly path and determine what causes valid descriptions to render blank; done means the catalog consistently preserves descriptions or reports the failure instead of silently omitting them.