I got the following request from a community member:
How do you feel about handling known-accepted frontmatter fields that are technically outside the spec? For example, I'm trying to use skill-validator against some skills have the user-invokable frontmatter, which is outside the spec but actively used by Claude Code. Because of this, my skills are failing validation.
Is this a time to rely on not using the --strict flag (which I don't feel great about), or is there space for this gray area?
Given that I don't have any information about how skill support is implemented across the platforms, I've been leaning on the spec as my best hope to ensure that skill content is interoperable across platforms. If user-invokable is a known Claude Code pattern, that doesn't necessarily mean it works in Cursor or Codex or any of the other tools.
BUT the community member wants to optimize for Claude Code, and the tool should still be available for folks who want to optimize for a specific platform.
For this case, I think an optional ‘--accept-nonstandard-frontmatter’ flag could be a reasonable escape hatch. The tooling could validate the standard frontmatter per the current behavior and also “ignore” any non-standard fields for people who specify the flag. It would not provide any validation for the "known accepted" non-standard fields - i.e. we won't try to validate that it's spelled correctly or uses the correct type for the field. But it won't warn or error. Since it's an optional flag, the default behavior would still be the "safest" - and then folks who know they want to use non-standard fields can still benefit from the tool.
I got the following request from a community member:
Given that I don't have any information about how skill support is implemented across the platforms, I've been leaning on the spec as my best hope to ensure that skill content is interoperable across platforms. If
user-invokableis a known Claude Code pattern, that doesn't necessarily mean it works in Cursor or Codex or any of the other tools.BUT the community member wants to optimize for Claude Code, and the tool should still be available for folks who want to optimize for a specific platform.
For this case, I think an optional ‘--accept-nonstandard-frontmatter’ flag could be a reasonable escape hatch. The tooling could validate the standard frontmatter per the current behavior and also “ignore” any non-standard fields for people who specify the flag. It would not provide any validation for the "known accepted" non-standard fields - i.e. we won't try to validate that it's spelled correctly or uses the correct type for the field. But it won't warn or error. Since it's an optional flag, the default behavior would still be the "safest" - and then folks who know they want to use non-standard fields can still benefit from the tool.