Comparison · agent skill managers · features not UI

ainb skill-manager vs. xingkongliang/skills-manager

One-line verdict They built a skill library + marketplace client (SQLite-backed, skills.sh discovery, deliberately skill-only). We built a multi-surface unit manager that also handles Claude plugins, does bidirectional repo ↔ home sync with push-back, and maps folders per-tool (YAML manifest, no marketplace). Different centre of gravity — their gravity is discover & collect, ours is reconcile & publish.

The two products at a glance

Both are Rust, both sync skills to many coding-agent homes. That's where the overlap ends.

THEMskills-manager

xingkongliang/skills-manager · Tauri 2 desktop GUI + CLI

A mature skill library and marketplace client. One central repo at ~/.skills-manager/ + a SQLite DB; skills copied/symlinked out to each tool. Browse skills.sh, install, adopt your own, auto-update on a schedule, tag, version-snapshot.

⭐ 1.8k v1.22.5 · 46 releases store: SQLite tools: 15+ scope: skills only

USainb skill-manager

agents-in-a-box · ratatui TUI + CLI

A reconciler for units across tool homes and source repos. YAML manifest.yaml + lock.yaml; discovers marketplace plugins AND orphan skills, maps each unit's files per-tool, and syncs both directions (incl. publishing your local edits back upstream).

store: YAML tools: 9 adapters scope: skills + agents + commands + PLUGINS sync: bidirectional

Capability matrix

✅ full · ◑ partial · ✘ none. Rows where we lead are marked with a clay edge.

Capability	them	us	note
Claude marketplace plugins	✘	✅	Our differentiator. They deliberately exclude the plugin cache (CHANGELOG v1.14.0: "avoid false positives from plugin marketplace caches"). Our Class-A walker reads `.claude-plugin/plugin.json` and surfaces `marketplace:<plugin>@<mp>`.
Bidirectional sync (local edit → upstream)	◑	✅	Theirs is central↔project only; no remote git push-back, and they don't detect dirty installed skills. Ours: `apply_to_repo` commits + pushes your home-side edits back to the source repo.
Per-tool folder mapping (fan-out)	◑	✅	They copy/symlink to `.<tool>/skills`. Ours has `target_layout` glob→home/repo mapping so one source publishes to arbitrary subdirs across tools.
Multi-unit-type (agents, commands, mcp, hooks)	✘	✅	They are SKILL.md-only by spec. We discover/manage agents, commands, mcp-servers, hooks too.
Discover on-disk skills	✅	✅	Both scan tool homes. Ours pops a discovery banner on empty-state; theirs lists in a Global Workspace.
Adopt on-disk skills into managed state	✅	✅	Theirs: `skills adopt --git-url --git-subpath`. Ours: banner `[Enter]` import + `promote` (local→git source).
Install from remote git	✅	✅	Theirs accepts more shapes (ssh, tree/branch/subpath URLs, zip/.skill archives). Ours: `gh:`/`git:`/`https:`/`local:` URIs.
Drift detection vs upstream	✅	✅	Both compare stored SHA vs remote HEAD. Ours renders ✓/⚠/▲/⟷ glyphs via background `git ls-remote` poll.
Update / remove / install in-product	✅	✅	Both CLI + GUI/TUI. Our TUI help-bar keys (`i/u/c/r/s//`) were just fully wired.
Provenance tracking	✅	◑	They lead. SQLite stores source_type / ref / resolved-ref / subpath / branch / revision / content_hash. Ours: a provenance matcher is designed but not built — externally-cloned skills currently read as `local:`.
Browse remote catalog before install	✅	✘	They lead — big gap for us. `skills search` → skills.sh `/api/search` + trending/hot. Our `[/]` search only filters already-installed units.
Own-skill library / upload	✅	◑	They lead. v1.19 first-class "upload a local-only skill into central library". Ours: adopt + promote exist, but no first-class personal library UI.
Auto-update scheduler	✅	✘	They lead. Polls every 15 min (1h/6h/24h configurable). We have no background updater.
Tagging / filtering	✅	✘	They lead. `skill_tags` table + tag CRUD. We have no tags.
Git-backed version history / restore	✅	◑	Theirs snapshots the whole `~/.skills-manager` repo (`git versions/restore`). Ours relies on the source repos' own history + the lockfile.
`external-dependencies.yaml` provenance	✘	◑	Neither reads it today, but ours is designed to (matcher correlates installed_plugins.json + external-deps.yaml → real `gh:` URIs). Theirs has no such manifest concept.
Storage model	SQLite	YAML	Theirs: queryable DB, strong for tags/search/provenance. Ours: human-readable, git-diffable, no query engine.

The plugin question, answered loud

⬡

We are the only one that manages Claude plugins. skills-manager knows ~/.claude/plugins/cache exists and treats it as noise to filter out — its detection rule is "a directory is a skill iff it contains SKILL.md", and plugin.json / .claude-plugin/ are out of scope by spec. ainb's Class-A walker does the opposite: it reads the plugin manifest, understands a plugin as a bundle of skills, and emits marketplace:<plugin>@<marketplace> URIs. If "manage my installed plugins" is the job, they don't do it and aren't trying to.

The marketplace & own-skill question — our two biggest gaps

⚠

They have a front door; we don't. Their whole left-half of the product is browse skills.sh → preview → install, plus a first-class "upload my own skill into a central library". We have discover-what's-already-on-disk (the banner) + promote + adopt — powerful for reconciliation, but there is no catalog to browse before you install and no personal skill library as a first-class surface. For a user whose mental model is "where do I find new skills and keep my own", they win today.

User-journey comparison

Same goal, two products, side by side.

① "Install a skill I found on the internet"

them — skills-manager

skills search "react" → skills.sh hits (or browse trending in GUI)
skills install owner/repo --skillssh (GUI previews into temp, you pick skills)
Provenance recorded in SQLite (resolved URL, branch, revision, hash)
skills sync --preset p → copied into every tool home

Smooth — discovery is built in.

us — ainb skill-manager

You already know the URI (no catalog) — [i] add source gh:owner/repo
ainb skill install gh:owner/repo@main/skills/x --targets claude,codex
ainb skill check → drift glyph

Works, but you must arrive with the URI — no "find new skills" step.

② "Manage / share a skill I wrote myself"

them — skills-manager

Drop the SKILL.md folder anywhere → skills adopt <path> (or GUI "upload local skill")
Enters central library as source_type: local
Add to a preset, skills sync to push to agents
To share: git push the whole ~/.skills-manager repo

First-class personal library; sharing is repo-wide, not per-skill.

us — ainb skill-manager

Author in your tool home; the discovery banner finds it as an orphan
[Enter] import → manifest gains a local: unit
ainb skill promote → pushes it into a git repo, rewrites local: → gh:
Thereafter ainb skill sync --to-repo publishes future edits

Per-skill promote + push-back is cleaner for sharing — but no "library" home to see all your own skills.

③ "Adopt skills already installed on my machine"

them — skills-manager

Global Workspace auto-scans ~/.claude/skills etc.
skills adopt <paths> --git-url --git-subpath backfills provenance

Provenance backfill is a nice touch.

us — ainb skill-manager

Open SkillManager (m) → discovery banner enumerates orphans and plugins
[Enter] import all → manifest populated
[m] re-runs discovery anytime

We also surface marketplace plugins here — they can't.

④ "Manage a Claude marketplace plugin"

them — skills-manager

— not supported —
The plugin's bundled SKILL.md might be ingested as a bare skill, but the plugin (and its agents/hooks/mcp) is invisible.

Out of scope by design.

us — ainb skill-manager

Discovery banner shows "Marketplace plugins: N"
Import → marketplace:<plugin>@<mp> URI in the manifest
Drift + sync treat it like any other unit

The whole journey only exists on our side.

The shopping list

What to steal from them

Their genuinely-ahead features — ranked by user impact.

Catalog browse before install — a skills.sh-style search surface; our single biggest UX gap
First-class own-skill library — a "my skills" home + upload, not just adopt/promote
Auto-update scheduler — background drift→update on a cadence
Dirty-skill detection — flag locally-modified installed units (we have the hashes already)
Tagging — cheap, high-value for large libraries
SQLite-grade provenance — our matcher should land the same columns

What we have they don't

Our moat — keep investing here.

Claude plugin management — the only one; they filter it out
Bidirectional sync with push-back — publish local edits to the source repo
Per-tool folder-mapping fan-out — target_layout glob→home/repo
Multi-unit-type — agents, commands, mcp-servers, hooks, not just skills
external-dependencies.yaml provenance — once the matcher lands
YAML, git-diffable state — no opaque DB; reviewable in a PR

Recommendation

We are not building the same product — and shouldn't. skills-manager owns "discover and collect skills from a marketplace"; ainb owns "reconcile every unit (incl. plugins) across tool homes and publish edits back". Our differentiators — plugin management, bidirectional push-back, folder-mapping, multi-unit-type — are real and theirs by neither accident nor oversight (they explicitly declined plugins).

But two of their features are table-stakes UX we're missing: a catalog to browse before install and a first-class own-skill library. Without the first, every install starts with "go find the URI yourself"; without the second, a user's own skills have no home. Prioritise those two next, then the provenance matcher (which also unblocks dirty-skill detection and proper external-dependency attribution). Tagging and the auto-update scheduler are cheap follow-ups.