runkids/skillshare: one skill source for every AI CLI

The problem is that every AI CLI keeps its own skills folder

Claude Code reads skills from one path. Codex reads from another. Cursor, OpenCode, OpenClaw and the rest each expect their own layout. The README states the failure mode plainly: you edit a skill in one tool, forget to copy it to the others, and lose track of what lives where. That is not a hypothetical, it is the normal outcome of running two or three agents on one laptop.

skillshare treats one directory as the source of truth and pushes its contents outward. On macOS and Linux the source lives at `~/.config/skillshare/`, split into `skills/`, `agents/` and `extras/`. On Windows it is `%AppData%\skillshare\` with the same three subdirectories. The audience is narrow and specific: developers who already juggle several AI CLIs, and teams that want the same prompts and rules available to everyone without a shared drive. If you use exactly one agent and never share anything, this tool adds a layer you do not need.

Symlinks, junctions and a declarative source of truth

The mechanism is link-based rather than copy-based. On macOS and Linux, `skillshare sync` creates symlinks from each target tool's expected directory back into the source tree. On Windows it uses NTFS junctions, which the README notes do not require administrator rights. Because the link points at the source, editing a skill once changes it everywhere at the next sync without any duplication.

The repository is a single Go module (`module skillshare`, `go 1.25.5`). The dependency list is almost entirely terminal rendering: bubbletea, lipgloss, glamour, pterm, go-runewidth. That tells you what the tool is: a TUI-first CLI with no service component and no database. The README claims no registry, no telemetry and fully offline capability, which is consistent with a binary that only touches local files and, when you explicitly ask it to, a Git remote.

The source tree is split by resource type rather than by tool. Skills are `SKILL.md` files under `skills/`, agents under `agents/`, and everything else (rules, commands, prompts) under `extras/`. A target only receives the categories it supports, which is why the README describes agents syncing to "agent-capable targets" rather than to all of them.

Installing skillshare and running the first sync

The README gives three install paths. On macOS and Linux the install script is piped to a shell:

curl -fsSL https://raw.githubusercontent.com/runkids/skillshare/main/install.sh | sh

On Windows PowerShell the equivalent script is fetched and executed:

irm https://raw.githubusercontent.com/runkids/skillshare/main/install.ps1 | iex

Homebrew users can install from the formula instead:

brew install skillshare

After install, the README points to `skillshare upgrade` for updates and says it auto-detects the install method. The quick start begins with initialization, which the README describes as creating the config, the source directory and detecting targets:

skillshare init

From there the sync command is the one you will run most:

skillshare sync

The README does not show the exact console output of `init` or `sync`, so expect a target-detection step and a per-target result list rather than anything documented here. For CI, the project publishes a GitHub Action, and the README's example passes a source path and then runs sync:

- uses: runkids/setup-skillshare@v1
  with:
    source: ./skills
- run: skillshare sync

Optional shorthand is an alias in your shell config:

alias ss='skillshare'

There is also a web interface, `skillshare ui`, which the README lists as a differentiator against install-per-command tools. The UI directory exists in the repository root alongside a Docker sandbox compose file, so the browser dashboard is a real component and not a mockup.

Filtering, scope and the parts the README leaves thin

Not every skill belongs in every tool, and skillshare handles that with three overlapping controls: a `.skillignore` file, a `targets` field inside `SKILL.md`, and per-target include/exclude configuration. The repository root does contain a `.skillignore`, so the mechanism is in use in the project itself. Three ways to express the same intent is one more than most people need, and the README does not explain precedence between them. That is a real gap: if a skill is listed in `.skillignore` and also named in a target's include list, the documentation does not say which wins.

Version control scope is another area where the README is honest about complexity rather than hiding it. Release v0.20.0 introduced a `git_root` scope that lets you choose whether `commit`, `push` and `pull` operate on skills, agents, extras, or all of them together in one repository. That flexibility exists because teams disagree about whether agents and skills belong in the same repo. The cost is that the same three commands behave differently depending on configuration, and the README does not document a rollback path if a pull overwrites local edits.

The same release added extras extension transforms, which convert Markdown into native formats during sync, specifically Gemini TOML commands and Codex TOML agents. That is a format translation layer, not just file placement, and it is the kind of feature where a wrong mapping is quiet rather than loud. The README does not list which Markdown structures map to which TOML fields.

Security audit is the second product inside the first

The README lists a built-in audit that scans skills for prompt injection and data exfiltration, and says it runs automatically on install and update. Screenshots in the README show a TUI audit view. The Makefile goes further than most projects do here: there are dedicated targets named `test-redteam`, `test-redteam-signal` and `test-redteam-rules-signal`. The help text describes the last one as verifying that the red team test fails when critical builtin rules are disabled. That is a mutation test on the detector itself, which is a stronger signal about intent than a feature bullet.

It is still a pattern-matching audit. A skill that describes an exfiltration step in prose rather than in a shell command is exactly the case a rule-based scanner struggles with, and nothing in the README claims semantic analysis. Treat the audit as a filter that catches obvious payloads, not as a reason to install skills from strangers without reading them. The project also supports installs from GitHub, GitLab, Bitbucket, Azure DevOps and self-hosted Git, so the audit is the only gate between a remote repository and your agent's instructions.

How it differs from install-per-command skill managers

The README draws its own comparison against imperative, install-per-command tools, and the distinction is worth taking seriously. Those tools copy each skill into each target independently. Setting up a new machine means re-running every install by hand. skillshare inverts that: you clone your config directory and run `sync`, and the links are rebuilt from one source.

The second difference is runtime dependency. The comparison table lists Node.js and npm as the requirement for install-per-command tools and "None (single Go binary)" for skillshare. If your team already has Node everywhere, that advantage is small. If you are provisioning a fresh machine or a CI runner, a static binary that needs no package manager is a shorter path, and the GitHub Action exists precisely for that case.

The third difference is the audit and the web dashboard, both of which the README lists as absent from the imperative approach. Neither is unique in the abstract, but bundling them into the same binary that does the syncing is the actual design choice here. The trade-off is that you are adopting a fairly large tool to solve what is, at bottom, a file-linking problem.

Maintenance, licence and upgrade cost

The last push to the default branch was on 2026-09-10, and the most recent release, v0.20.29, was tagged the same day. Releases v0.20.27 and v0.20.28 landed on 2026-09-02 and 2026-09-09. The repository is not archived. That cadence means upgrades arrive often, and the README points to `skillshare upgrade`, which it says auto-detects the install method. A tool that ships multiple patch releases per week is one where pinning a version in CI is worth the effort, and the GitHub Action documentation is listed as supporting version pinning.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with no copyleft obligation on your own code. It says nothing about the licences of the skills you sync, which are separate works with their own terms. This is not legal advice; if you redistribute a bundle of third-party skills inside a product, check each skill's licence rather than the tool's.

The upgrade cost is mostly configuration drift. Because targets are detected and links are created, a new release that changes a target's expected path will silently stop syncing that tool until you re-run `init` or update the target config. The README does not describe a migration step for that scenario, so the practical check after any upgrade is whether every expected target still appears in the sync output.

Editorial conclusion

Adopt skillshare if you run more than one AI CLI on the same machine and are tired of copying SKILL.md files by hand, or if a team needs a shared, versioned skills directory. Skip it if you only use one agent and never share prompts, because a single symlink would do the same job. Before trusting it, run an install in a scratch config directory and inspect what the symlink or NTFS junction points at, since the README does not document a rollback path for a sync that overwrites an existing target directory.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. runkids/skillshare on GitHub