SKM-P04 · Portability
`metadata.openclaw.*` / `command-dispatch` / `user-invocable` are OpenClaw-only fields
Dependency gating, tool-dispatch, and invocation controls specific to OpenClaw.
What the rule is
`metadata.openclaw.requires` / `os` / `install`, and the top-level `command-dispatch` and `user-invocable` fields, are OpenClaw-specific extensions. The `requires`/`os`/`install` trio does dependency gating — the skill hides when a required binary, environment variable, or platform is absent.
Outside OpenClaw, what happens to these fields isn't documented anywhere we've found. If they're silently ignored, the skill loses its dependency gating and could appear even where it can't run — but we hold no runtime-specific evidence that any of the other four runtimes actually handle it that way, as opposed to, say, treating the unrecognised field as a validation problem the way the official reference validator does.
These two groups aren't the same case for strict spec conformance, and testing them separately matters: `command-dispatch` and `user-invocable` sit at the top level of the frontmatter and fail the official reference validator outright, the same as any other unrecognised field. `metadata.openclaw.*` is nested inside the already-valid `metadata` field, whose contents the reference validator doesn't inspect — so a skill using only the nested form passes strict validation even though the field is still OpenClaw-only in practice.
Where it comes from
- OpenClaw — official skills documentationRuntime documentation
- Agent Skills compatibilityAgentSkills.site
- Agent skills not workingAgentSkills.site
Strict spec conformance
Non-conformant. The official reference validator (skills-ref) rejects this — tested directly, not inferred from severity.
This is a separate question from the severity above and from which runtimes enforce it below — a rule can be a real, working extension in its home runtime while the reference validator still rejects the file outright, or vice versa. Both facts are reported, never one inferred from the other.
Which runtimes enforce it
| Runtime | Effect | Note |
|---|---|---|
| Claude Code | Not documented | Not documented for this runtime — we hold no runtime-specific evidence either way. |
| Codex | Not documented | Not documented for this runtime — we hold no runtime-specific evidence either way. |
| Cursor | Not documented | Not documented for this runtime — we hold no runtime-specific evidence either way. |
| OpenClaw | Enforced (home runtime) | The field's home runtime — e.g. `metadata.openclaw.requires` hides the skill when its dependency is absent. |
| Hermes Agent | Not documented | Not documented for this runtime — we hold no runtime-specific evidence either way. |
How to fix it
- If the skill depends on something OpenClaw's gating fields express, restate that dependency in the skill's instructions too, so a runtime that doesn't read the gating field still tells the agent what's required.
Elsewhere
- SKILL.md, the formatThe full frontmatter field table this rule is drawn from.
- Agent Skills Not WorkingThe diagnostic reference this rule’s portability and failure evidence comes from.
- All rulesEvery check the validator runs, grouped by class.