Using trailofbits/skills as a test corpus — small parser-spec finding (SKILL.md version field)

Hi Trail of Bits — while building an open-source lockfile + PR-review tool for Claude Code / Codex skills (SkilLock, Apache 2.0), I used your skills repo as one of two real-world test corpora during parser development. One small finding worth sharing:

.codex/skills/gh-cli/SKILL.md (and apparently most of the OpenAI Codex corpus) omits a version: field in the YAML frontmatter. Our v0.1.0 parser was incorrectly rejecting any SKILL.md without version: — running it against your file caught the bug early. We shipped v0.1.1 making the field optional (which is the correct reading — Codex spec leaves version: optional, same as Claude Code).

No action needed on your end. Sharing because:

1. Your skills repo is a great test target precisely because it covers real-world variations that synthetic fixtures miss. Thank you for keeping it public.
2. If anyone else is building tooling around the SKILL.md format and reading this, the parser fix path is optionalString on the version field — don't require it.

For context: the tool is at https://github.com/skills-lock/skil-lock. It pins approved skill behavior (shell, network, file surface) into a skills.lock and runs a capability-delta PR review. If lockfile-style behavior pinning for your own skills feels useful in your workflows, happy to chat; otherwise feel free to close.