Remove openclaw metadata from skills

[gerfalcon]

Problem

The SKILL.md files in /skills/ include openclaw metadata in their YAML frontmatter:

metadata:
  openclaw:
    category: "productivity"
    requires:
      bins: ["gws"]
    cliHelp: "gws calendar --help"

This appears across all skills (gws-calendar, gws-gmail, gws-drive, etc.).

Why this is problematic

1. Vendor lock-in on an open format — Agent skills are just markdown files with YAML frontmatter. Introducing a third-party registry standard (openclaw) as metadata creates an unnecessary dependency on an external specification that doesn't govern how skills are consumed.

2. Skills should be tool-agnostic — The name, version, and description fields in the frontmatter are sufficient. Categorization and binary requirements can be expressed without adopting an external standard.

3. Confusion for contributors — Developers looking at these skills may assume openclaw is a required part of the skill format, when it has no effect on how Claude Code (or any other AI coding agent) processes the skill.

Suggestion

Remove the openclaw block from the frontmatter and keep the existing standard fields (name, version, description). If categorization or requirements metadata is needed, use flat keys that don't reference an external standard:

---
name: gws-calendar
version: 1.0.0
description: "Google Calendar: Manage calendars and events."
category: productivity
requires:
  bins: ["gws"]
cliHelp: "gws calendar --help"
---

[gerfalcon]

Update: I noticed the publish-skills.yml workflow uses clawhub sync to publish skills to the OpenClaw registry, which likely requires the metadata.openclaw block in the frontmatter.

Instead, I'd like to reframe this as a question:

Should these skills be coupled to a third-party registry (OpenClaw/ClawHub)?

If OpenClaw integration is intentional and staying, it would help to:

1. Document in the README why metadata.openclaw exists and what it's used for
2. Clarify whether the openclaw fields are required for skill authors contributing new skills

[balthazar-bot]

I think the update already points at the real issue: this is mainly a documentation / ownership boundary problem, not necessarily a metadata problem.

I checked the repo and the current workflow literally does clawhub sync --root skills --all, so metadata.openclaw is not random decoration here — it is part of the publish pipeline for this project today.

That said, I agree the current setup is confusing for contributors because the runtime format and the distribution format are blended together in the same frontmatter.

A pragmatic middle ground could be:

1. Keep the metadata for now if ClawHub publishing depends on it.
2. Document it explicitly in the README / contribution guide as “registry metadata used at publish time”, not as a universal requirement of SKILL.md.
3. Optionally later, generate the registry-specific block at publish time from a simpler internal manifest if you want cleaner source files.

So my take: I wouldn’t remove it blindly, but I would make the contract explicit. Right now the field looks like vendor lock-in; with one short doc section it becomes understandable build metadata instead of mysterious lore.