Skip to content

Expand skill import sources beyond GitHub (GitLab, Bitbucket, skills.sh, skild) #79

@devrimcavusoglu

Description

@devrimcavusoglu

Summary

skern skill import <url> currently supports only GitHub-hosted skills:

  • https://github.com/<owner>/<repo>/tree/<ref>/<path> (repo directory)
  • https://gist.github.com/<user>/<gist-id> (gist)

The community is rapidly producing skill catalogs and registries on other hosts. Skern should treat skill-source plurality as first-class so the registry isn't tied to one git host.

Sources to support

Other git hosts (parity with GitHub):

  • GitLabhttps://gitlab.com/<owner>/<repo>/-/tree/<ref>/<path>. Public REST API similar to GitHub's; archive endpoints exist for grabbing a subtree.
  • Bitbuckethttps://bitbucket.org/<owner>/<repo>/src/<ref>/<path>. Has a REST API (api.bitbucket.org/2.0) for tree listing and raw file fetch.
  • Generic git over HTTPS / SSH — fall back to git clone with sparse checkout when the host isn't recognized. Useful for self-hosted Gitea / Forgejo / SourceHut.

Skill catalogs / registries:

  • skills.sh — community catalog. Need to determine: is there a stable URL scheme per skill? An API? Or do entries link out to underlying git repos (in which case the resolver becomes `skills.sh URL → git URL → existing import path`)?
  • skild hub — similar question. Likely a curated set of skills with stable per-skill URLs that resolve to a fetchable artifact.

Out of scope (for now)

Export. Pushing skills to an external host (publishing) is not on the short-term roadmap. This issue covers import only. A separate `skill export` / `skill publish` issue can be filed when the demand is clear.

Current architecture

Import lives in internal/skill/importer.go. The dispatch happens in `ParseImportURL` (line 56) by matching on `url.Host`:

```go
case "gist.github.com": ...
case "github.com": ...
default: return error
```

`Fetch(src, client)` then dispatches on `src.SourceType` to `fetchFromGitHubRepo` / `fetchFromGitHubGist`. The CLI surface in internal/cli/skill_import.go is host-agnostic.

Suggested approach

The current `ParseImportURL` + `Fetch` dispatch is already a strategy pattern keyed on `SourceType`. Adding hosts is mostly:

  1. New `SourceType` constants (`SourceGitLabRepo`, `SourceBitbucketRepo`, `SourceSkillsSh`, `SourceSkild`, `SourceGitGeneric`).
  2. New host case in `ParseImportURL` for each.
  3. New `fetchFromX` function per source.
  4. Update the help text and the "unsupported host" error to list new hosts.

Cross-cutting concerns to design before coding:

  • Auth — GitLab/Bitbucket private repos need tokens. Reuse the GitHub token mechanism (env var `SKERN_GITHUB_TOKEN`?) or introduce `SKERN_GITLAB_TOKEN`, `SKERN_BITBUCKET_TOKEN`. Consistency with how GitHub auth currently works is important.
  • Rate limits — each host has different limits. Surface them in error messages.
  • Generic git fallback — adds a `git` runtime dependency. Decide whether to require it or to recommend it as an opt-in (`--allow-git-clone` flag?).
  • Catalog resolvers — skills.sh / skild may not be raw git fetches. They might need their own API layer that resolves a catalog ID to a downloadable artifact. Worth investigating their actual delivery mechanism before estimating scope.

Acceptance criteria

  • `skern skill import` accepts public GitLab repo-directory URLs.
  • `skern skill import` accepts public Bitbucket repo-directory URLs.
  • `skern skill import` accepts at least one of skills.sh / skild URLs (the more tractable of the two — design discussion needed first).
  • Auth strategy is documented for each host.
  • Help text and error messages list every supported source.
  • Tests cover each new source type with httptest fixtures.

Investigation needed

  • Confirm skills.sh and skild URL/API shapes — file a follow-up if they require deeper API integration than a simple URL resolver.
  • Decide on auth env-var naming convention before adding the second host.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestneeds-discussionRequires design discussion before implementation

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions