feat(skills): add curated remote skill source backed by gitlab.com

Kai Armstrongrequested to merge
karmstrong/skills-remote into main

Description

Follow-up to !3237 (merged) (which itself follows !3235 (merged)). Adds support for installing agent skills that live in public gitlab.com projects, via a curated registry maintained in this repo.

Architecture

Three new packages under internal/commands/skills/:

  • skill — shared types only (Skill { Name, Description, Source, Files } and a Source enum).
  • registry — aggregator over every source. Owns the user-facing "unknown skill" error and uses per-source ErrNotFound sentinels so genuine load/network failures propagate unmasked.
  • remote — gitlab.com source. registry.yaml is the curated list, embedded via //go:embed. All() is fully offline (description comes from the YAML). Get(name) fetches the whole skill directory tree anonymously via the Repository APIs. The latest ref is special-cased to the project's default branch; tags, SHAs, and other refs pass through unchanged.

install and list now consume the aggregator instead of bundled directly. list gains a Source column so users can tell where a skill comes from before installing.

Maintainer tooling

scripts/skills/add-remote takes a gitlab.com tree/blob URL, fetches the SKILL.md, parses its frontmatter, and writes a sorted registry entry. Catches the most common copy-paste mistakes (frontmatter name not matching the skill directory) and normalizes branch-like refs to latest.

First remote skill

orbit is registered with ref: latest so updates from the Orbit team don't need a registry MR. Multi-file install works end-to-end — Orbit ships SKILL.md plus a references/ directory, both round-trip.

Trust model

Curation in this repo's MR history is the trust model. Approving an MR that adds an entry vouches for the publishing project + ref. With ref: latest, our trust shifts to "this project's maintainers" rather than "this content" — same model as apt-get install. Per-entry tightening to a tag or SHA is available for any skill that warrants stricter pinning.

Why not the agentskills.io skills-ref validator

Its README states "This library is intended for demonstration purposes only. It is not meant to be used in production." Same reasoning as in !3237 (merged) — we keep validation minimal and let MR review handle full spec compliance.

Related

Depends on !3237 (merged). Retarget to main (or to whichever ancestor merges first) as the stack progresses.

How has this been tested?

  • bundled, registry, remote, install, and list packages all have unit tests covering the new shape. remote/remote_test.go mocks gitlab.com via httptest (raw HTTP — fetcher doesn't use the client-go SDK so gitlabtesting doesn't apply).
  • Manually verified end-to-end:
    • glab skills list shows glab, glab-stack (bundled), and orbit (remote) with a Source column.
    • glab skills install orbit --path /tmp/x fetches the live SKILL.md plus the entire references/ directory.
    • glab skills install (no arg) installs only bundled skills; remote is opt-in by name.
    • glab skills install does-not-exist returns the registry's "unknown skill" error pointing to glab skills list.
    • go run ./scripts/skills/add-remote https://gitlab.com/gitlab-org/orbit/knowledge-graph/-/tree/main/skills/orbit produced the committed registry entry.
  • validate-skills lefthook hook now covers every package under internal/commands/skills/, so a bad remote registry entry fails locally at commit time.

Screenshots (if appropriate):

N/A

Merge request reports