Two bundled skills (ray-data, ray-train) silently fail to load: unquoted `ray[train]` breaks YAML frontmatter

[sprmdta]

Summary

Two bundled skills — ray-data and ray-train — are silently dropped by the skill loader because their YAML frontmatter is malformed. They never appear in openscience skill list --all, the / picker, or the Skills panel.

Root cause

Both files declare an unquoted Python extras spec inside a YAML flow sequence:

# backend/cli/skills/ml-training/ray-train/SKILL.md
dependencies: [ray[train], torch, transformers]

# backend/cli/skills/data-engineering/ray-data/SKILL.md
dependencies: [ray[data], pyarrow, pandas]

In a YAML flow sequence, the [ in ray[train] opens a nested sequence, so the block is invalid YAML. ConfigMarkdown.parse() throws, addSkill() returns early, and the skill is discarded.

Why it's easy to miss

The failure is silent from the user's side — no warning is surfaced in skill list, and the skill just isn't there. The count is simply short, with nothing to indicate why.

I only found it by counting SKILL.md files on disk (292) and diffing against the loaded set (289; 291 after the fix — the 292nd file, scholar-evaluation/SKILL.md, is a category README with no frontmatter).

Reproduce

# skills present on disk
find backend/cli/skills -name SKILL.md | wc -l          # 292

# skills the loader accepts
openscience skill list --all 2>&1 | head -1             # "bundled skills: 289"

# the two that vanish
grep -rn '^dependencies:.*[a-z]\[' backend/cli/skills --include=SKILL.md

Confirmed on v1.3.4. These are the only two files in the tree matching the pattern.

Fix

Quote the extras so YAML treats them as scalars:

- dependencies: [ray[train], torch, transformers]
+ dependencies: ["ray[train]", torch, transformers]

- dependencies: [ray[data], pyarrow, pandas]
+ dependencies: ["ray[data]", pyarrow, pandas]

With that change the loader reports 291 bundled skills and both Ray skills appear.

Suggestion

Consider surfacing frontmatter parse failures for bundled skills (a log.warn at minimum, as already happens for duplicate names). A skill that silently doesn't exist is much harder to diagnose than one that loudly fails to load — and a CI check that every SKILL.md in the tree parses would catch this class of bug before release.

Happy to send a PR if useful.