catalog.yaml: name the skills that cover each library (libraries[].skills) #7

Summary

Add an optional skills field to each entry of libraries in plugins/<plugin>/catalog.yaml. It names the skills of the plugin that cover that library. It's passed through to catalog.json and bundle.catalog() (#5).

# plugins/rf-web/catalog.yaml
libraries:
  - name: Browser
    package: robotframework-browser
    versions: ">=20,<21"
    skills: [rf-browser]
  - name: SeleniumLibrary
    package: robotframework-seleniumlibrary
    versions: ">=6.9,<7"
    skills: [rf-selenium]

Purpose

libraries[].package is already described as "used to detect the library in a project". Detecting a library is only half the job, though. A tool also has to know which skill to hand the agent, and the catalogue maps libraries to a plugin only. A plugin can ship several skills for different libraries:

So a project that uses only Browser can't be pointed at rf-browser alone. A tool has to name every skill of rf-web, or guess.

rf-mcp now uses the catalogue this way. On an agent's first tool call it lists the packages installed in the project and attaches the matching skills, and its hints link to skill sections. In its evaluation against this repository at 37562367, matching on the plugin level went wrong. A Browser project that also had RequestsLibrary installed got rf-requests, rf-restinstance and rf-browser, in that order, because rf-api sorts before rf-web. rf-mcp now guesses from the skill names (Browser → rf-browser, RequestsLibrary → rf-requests). That works for today's plugins, but it's a naming convention, not a contract. A skill such as rf-api-auth or a company plugin would break it.

The installer could use the field too. install --plugins installs whole plugins today, while a per-library list would let it install rf-browser without rf-selenium for a Browser-only project.

Proposed change

1. Schema. In schemas/catalog.schema.json, add to libraries.items.properties (the items have additionalProperties: false, so the field is rejected today):

   "skills": {
     "description": "Skills of this plugin that cover the library. Omit when every skill of the plugin applies.",
     "type": "array",
     "items": {"type": "string", "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$"},
     "minItems": 1,
     "uniqueItems": true
   }

2. Validation. scripts/build-catalog.py --check fails when a listed skill has no plugins/<plugin>/skills/<skill>/SKILL.md.
3. Data. Fill in the field for the current plugins:
   • rf-web: Browser → rf-browser, SeleniumLibrary → rf-selenium;
   • rf-api: RequestsLibrary → rf-requests, RESTinstance → rf-restinstance;
   • rf-mobile: AppiumLibrary → rf-appium;
   • rf-desktop: PlatynUI → rf-platynui.
4. Output. catalog.json in the installer bundle, and with it bundle.catalog() from Public Python API for the bundled catalogue and skill folders (for rf-mcp) #5, carries the field unchanged. docs/catalog.md can show it.

The field is optional, so existing catalogues and readers keep working. A reader that finds no skills treats every skill of the plugin as covering the library, which is what it has to assume today.

Acceptance criteria

• The schema accepts libraries[].skills and still rejects other unknown keys.
• build-catalog.py --check reports a listed skill that doesn't exist, naming the plugin, the library and the skill.
• The catalogues of rf-web, rf-api, rf-mobile and rf-desktop list the skills per library.
• catalog.json, and bundle.catalog() once Public Python API for the bundled catalogue and skill folders (for rf-mcp) #5 lands, contain the field.
• CONTRIBUTING.md (or wherever catalog.yaml is documented) explains the field.

Related: #5 (public API for the bundled catalogue).