skilljit

Just-in-time-Routing von Skills und MCP-Tools für Claude – installiere Tausende von Skills zu den Token-Kosten von einem. Nichts wird in den Kontext geladen, bis eine Aufgabe es tatsächlich benötigt.

Warum sich die Tool-Liste nie ändert

Der naheliegende Weg, Tools bei Bedarf hinzuzufügen, ist die MCP-Benachrichtigung notifications/tools/list_changed. Sie ist in Claude Desktop defekt – anthropics/claude-code#50339 dokumentiert, dass sie über 336+ Versionen ignoriert wird (leere Client-Fähigkeiten, ein SDK-Handler, der nie ausgelöst wird, eine eingefrorene Tool-Listen-Referenz), und Anthropic hat das Issue als nicht geplant geschlossen. Der im Issue selbst empfohlene Workaround ist, „alle Tools beim Start zu deklarieren und intern über Modus-/Aktionsparameter zu verteilen."

Genau das macht skilljit. Seine MCP-Tool-Liste ist fest und ändert sich nie – eine kleine, konstante Handvoll Tools, immer. Skills und Upstream-MCP-Tools werden über diese Tools gefunden und geladen, nicht durch erneutes Registrieren der Tool-Liste. Deshalb funktioniert skilljit auf Claude Desktop, Claude Code, Codex und Cursor, während list_changed-basierte Proxys auf mindestens einem davon stillschweigend degradieren.

Related MCP server: context-saver

Das Problem

Claudes Agent Skills nutzen progressive Offenlegung: Jeder Skill mit name + description (~100 Token) liegt bei jeder Runde im System-Prompt, und nur der Body wird bei Bedarf geladen. Das funktioniert bei 10 Skills. Es bricht im großen Maßstab zusammen – das Ökosystem ist bereits da, mit Zehntausenden von Skills in Tausenden von Repos. 200 davon zu installieren kostet Zehntausende von Token pro Runde, für immer. Also macht es niemand – jeder installiert zehn und der Rest ist unerreichbar.

MCP hat das identische Problem, schlimmer: Die vollständigen Tool-Schemas jedes verbundenen Servers werden beim Start geladen, üblicherweise 20–50k Token, bevor der Benutzer irgendetwas tippt.

Installation

npx -y skilljit sync

Das ist der primäre Weg – das MCP-Ökosystem ist npx-first, und Claude Code / Desktop-Konfigurationen erwarten bereits diese Form.

Ein schlanker Python-Begleiter ist ebenfalls für claude-agent-sdk-Nutzer veröffentlicht, die denselben Katalog direkt abfragen möchten, statt über MCP zu gehen:

pip install skilljit

Siehe python/README.md für das, was dieses Paket kann und nicht kann – es leitet die CLI an npx -y skilljit weiter und fügt einen schreibgeschützten Catalog für Python hinzu.

Node-Versionsunterstützung

skilljit, @skilljit/mcp und @skilljit/proxy erfordern Node 18+ – diese Untergrenze stammt direkt von @modelcontextprotocol/sdk, von dem der MCP-Server und die Proxy-Schicht abhängen und das selbst 18+ erfordert. Es gibt keinen Weg daran vorbei, ohne die MCP-Unterstützung aufzugeben.

@skilljit/core (die Katalog-/Suchbibliothek, ohne MCP-Abhängigkeit) unterstützt Node 16+ für alle, die seine Catalog/ingestGithubRepo-API direkt verwenden. Auf Node 18+ ist dies eine Installation ohne Kompilierung (better-sqlite3 liefert ein vorgebautes Binärpaket). Auf Node 16/17 hat better-sqlite3 kein vorgebautes Binärpaket für diese ABI auf irgendeiner Plattform, daher fällt npm auf das Kompilieren aus dem Quellcode über node-gyp zurück – das benötigt eine C++-Toolchain und ein Python mit dem (vor-3.12) distutils-Modul. Das ist eine Standardanforderung für native Node-Module, kein skilljit-spezifischer Schritt, bedeutet aber, dass Installationen von @skilljit/core auf Node 16/17 nicht garantiert so reibungslos sind wie auf 18+.

Schnellstart

# 1. Build the local catalog from GitHub sources (SQLite, ~/.skilljit/catalog.db)
skilljit sync

# 2. Search it — no network call, no context cost
skilljit search "postgres migration"

# 3. Point your MCP client at the server
skilljit serve

Fügen Sie zu Ihrer MCP-Client-Konfiguration hinzu (z. B. claude_desktop_config.json):

{
  "mcpServers": {
    "skilljit": {
      "command": "npx",
      "args": ["-y", "skilljit", "serve"]
    }
  }
}

Andere Befehle: skilljit stats (Kataloggröße + wie man Live-Ersparnisse liest), skilljit init <configPath> (Vorschau der Weiterleitung Ihrer vorhandenen MCP-Server durch skilljit – mutiert das Original nie), skilljit adopt <configPath> (anwenden), skilljit doctor [configPath] (überprüfen, ob Upstreams noch funktionieren), skilljit restore <configPath> (macht adopt rückgängig).

Eigene Skills zu sync hinzufügen

Standardmäßig zieht sync nur aus einer kleinen kuratierten Liste öffentlicher Repos. Um eigene hinzuzufügen:

# Another public (or your-token-authenticated private) GitHub repo:
skilljit sync --repo your-org/internal-skills --token "$SKILLJIT_GITHUB_TOKEN"

# Any git remote at all — self-hosted, GitLab, Bitbucket, or a private repo
# reached over SSH — using whatever git credentials are already set up on
# this machine. No GitHub API token needed for this path.
skilljit sync --git git@git.internal.example.com:team/skills.git

Beide Flags sind wiederholbar. --git-Quellen werden über einen Bare-Mirror-Clone plus git worktree statt über die GitHub-API aufgenommen: Der erste Sync bezahlt einen vollständigen Clone, jeder Sync danach ist ein günstiges git fetch + Worktree-Checkout – kein Ratenlimit, kein Token, funktioniert gegen alles, was git selbst erreichen kann.

Die sechs Tools

skilljit bietet eine feste Oberfläche – sie wächst oder schrumpft nie zur Laufzeit.

skill_find → skill_load → skill_read_file ist progressive Offenlegung, neu aufgebaut als Pull, ganz nach unten: Die immer geladene Kosten hört auf, mit der Kataloggröße zu skalieren, und die gebündelten Referenzdokumente/-skripte eines Skills bleiben außerhalb des Kontexts, bis sie per Pfad benannt werden, selbst nachdem der Skill selbst geladen wurde.

tool_find und tool_call erscheinen nur, wenn Sie Upstream-MCP-Server über skilljit adopt konfiguriert haben (siehe unten) – führen Sie nur Skills aus, und die Oberfläche hat 4 Tools, nicht 6. Das macht die Skills-Hälfte unabhängig von der Proxy-Hälfte lieferbar und testbar.

Mehrere Tabs / parallele Sitzungen

Mehrere Claude Code-Tabs gleichzeitig für verschiedene Aufgaben zu betreiben, ist genau der Punkt, an dem sich die „jeder Tab zahlt für jeden installierten Skill"-Kosten multiplizieren – N offene Tabs bedeuten, dass dieser Overhead pro Runde N-mal gleichzeitig bezahlt wird. skilljit reduziert diese Kosten pro Tab bereits auf eine feste Handvoll Tools unabhängig von der Kataloggröße, aber skilljit_stats() geht weiter: Die Basis-/Ist-Zahlen jeder Sitzung werden auch in die gemeinsame catalog.db geschrieben (dieselbe Datei, auf die jeder skilljit serve-Prozess jedes Tabs bereits zeigt), sodass die gemeldeten Summen kumulativ über jeden Tab, den Sie offen hatten, sind, nicht nur den, von dem Sie fragen. Einen Tab zu verlieren, verliert diese Zahl nicht – sie wurde bereits dauerhaft geschrieben, nicht nur im Speicher dieses Tabs gehalten.

Das stellt nicht die Konversation eines verlorenen Tabs selbst wieder her – das ist eine Claude-Code-Sitzungsfunktion (claude --resume / --continue), unabhängig von skilljit. Was es gezielt behebt, ist der blinde Fleck der Token-Abrechnung: „Wie viel hat skilljit mir heute tatsächlich gespart, über alles, was ich offen hatte", das überlebt das Sterben eines einzelnen Tabs.

MCP-Proxy – Weiterleitung Ihrer anderen MCP-Server

Die Übergabe von skilljit serve --config <path> (der Konfigurationspfad, auf dem Sie zuvor skilljit adopt ausgeführt haben) aktiviert tool_find/tool_call für die übernommenen Server. Sicherheit steht hier an erster Stelle, da dies Konfigurationen betrifft, auf die Sie sich bereits verlassen:

• skilljit init <configPath> mutiert die Originaldatei nie – es schreibt eine vorgeschlagene Konfiguration und gibt einen Diff aus.

• skilljit adopt <configPath> ist standardmäßig ein Probelauf; übergeben Sie --yes, um die Änderung tatsächlich zu schreiben, nachdem Sie das Original gesichert haben.

• --keep server1,server2 lässt diese Server unangetastet – vollständig in der statischen Tool-Liste sichtbar, ohne tool_find-Roundtrip. Nützlich für Hot-Path-Tools, die Sie in jeder Runde aufrufen. (Keep ist pro Server, nicht pro Tool, in dieser Version.)

• skilljit doctor [configPath] überprüft, ob jeder übernommene Upstream noch startet, den Handshake macht und Tools auflistet.

• skilljit restore <configPath> ist ein Befehl, der die ursprüngliche Konfiguration zurücklegt.

• Ein nicht verfügbarer Upstream-MCP-Server beeinträchtigt die anderen nicht: tool_call gibt einen sauberen Fehler für diesen Server zurück, alles andere funktioniert weiter.

Sicherheit

Skills sind funktional Anweisungen von einem Fremden, denen ein Agent folgen wird – Anthropic warnt ausdrücklich, dass ein bösartiger Skill Daten exfiltrieren oder Tools missbrauchen kann. skilljit behandelt das als Feature, für das man entwerfen muss, nicht als nachträglichen Gedanken:

• Jedes skill_find-Ergebnis zeigt den Audit-Status des Skills neben seiner Beschreibung.

• skill_load warnt laut im zurückgegebenen Inhalt, wenn ein Skill seinen Audit nicht bestanden hat oder überhaupt nicht auditiert wurde – dieselbe Haltung wie beim Installieren von Software aus unbekannter Quelle.

Benchmark

bench/ liefert ein beschriftetes Set von 41 (Aufgabe → korrekter Skill)-Paaren und einen Recall@k-Harness, sodass „die Suche funktioniert" eine gemessene Behauptung ist und keine Stimmung. Aktuelle Zahlen, reproduzierbar mit node bench/run.mjs:

skilljit bench — 41 queries over 41 skills

recall@1: 37/41  (90.2%)
recall@3: 38/41  (92.7%)
recall@8: 41/41  (100.0%)

Die Suche ist SQLite FTS5 + BM25 – keine Embeddings in v1. Das ist eine bewusste YAGNI-Entscheidung: FTS5 ist identisch in beiden Implementierungen (Node (better-sqlite3) und Python (stdlib)) enthalten, ohne Modell-Download oder zusätzliche Laufzeitabhängigkeiten. Das verbleibende Recall-Risiko (Skill-Beschreibungen sind semantisch – „verwenden, wenn der Benutzer PDFs erwähnt…") wird strukturell gemildert: skill_find gibt mehrere Kandidaten zurück, die Claude in Betracht ziehen und erneut abfragen kann, statt sich auf ein One-Shot-Top-1-Ergebnis festzulegen. Embeddings bleiben eine optionale Option, die nur hinzugefügt wird, wenn dieser Benchmark zeigt, dass der FTS5-Recall wirklich unzureichend ist – die drei Fehlversuche oben (alle Beinahe-Treffer, korrekter Skill knapp außerhalb der Top 3) sind die konkreten Kandidaten für diese Entscheidung.

Veröffentlichung

Das Pushen eines v*-Tags (z. B. v0.1.2) führt CI aus und veröffentlicht dann jedes Paket auf npm und PyPI über Trusted Publishing (OIDC) – keine langlebigen NPM_TOKEN/PYPI_TOKEN-Geheimnisse in diesem Repo. Siehe .github/workflows/release.yml.

Einmalige Einrichtung erforderlich, bevor das funktioniert, manuell durchgeführt (kann nicht automatisiert werden):

• Auf npmjs.com einen Trusted Publisher für jedes von @skilljit/core, @skilljit/proxy, @skilljit/mcp und skilljit registrieren, der auf dieses Repo, die release.yml-Workflow-Datei und die npm-Umgebung zeigt.

• Auf pypi.org einen Trusted Publisher für das skilljit-Projekt registrieren, der auf dieses Repo, die release.yml-Workflow-Datei und die pypi-Umgebung zeigt.

Architektur

skilljit/
  packages/core/     catalog store, FTS5 index, ranking, token accounting
  packages/proxy/    upstream MCP server management, config adopt/restore, tool_find/tool_call routing
  packages/mcp/      the MCP stdio server (the fixed tool surface, see "The six tools" above)
  packages/cli/      skilljit sync | search | serve | stats | init | adopt | restore | doctor
  python/            pip package — CLI shim + read-only query API for Agent SDK users
  bench/             labeled task→skill eval set + recall@k harness

TypeScript ist die einzige Implementierung; das PyPI-Paket ist ein dünner, ehrlicher Wrapper darum, keine zweite Implementierung der Ranking-Logik.

Lizenz

MIT