Die sk-CLI auf deinem Rechner verwenden

Deine Engine liefert die CLI selbst aus. Es gibt kein npm-Paket. Du installierst sk einmal, meldest dich an und arbeitest dann im Terminal mit Workflows, Läufen und Konnektoren.

Was du brauchst #

Die Adresse deiner Engine, ohne Pfad. Die Beispiele nutzen http://localhost:3000. Für SubKit Cloud siehe das Kapitel „SubKit Cloud nutzen“.
Bash und curl.
Für einen API-Schlüssel auf einer selbst betriebenen Engine: Zugriff auf den Engine-Host.

Installieren und anmelden #

Installiere die CLI von deiner Engine: bash curl -fsSL http://localhost:3000/install | bash
Melde dich an: bash sk login --engine-url http://localhost:3000 Dein Browser öffnet sich. Nach der Anmeldung gibt sk die Zeile sk: signed in as … aus und speichert das Profil.
Starte mit sk. sk --help listet alle Befehle.

Die Engine beschreibt sich selbst unter /openapi.json und /llms.txt.

Mit einem API-Schlüssel anmelden #

Nutze diesen Weg für Skripte oder für eine selbst betriebene Engine ohne Anmeldeanbieter.

Erstelle auf dem Engine-Host einen Admin-Schlüssel. Der Befehl gibt eine fertige sk login-Zeile aus: bash docker compose exec engine engine --issue-admin-key --tenant my-org
Führe die ausgegebene Zeile aus. Die Zeile hat diese Form: bash sk login --engine-url http://localhost:3000 --api-key <key> sk gibt sk: profile 'default' saved und den Zustand der Engine aus.

Aus einem öffentlichen GitHub-Release installieren #

Nutze diesen Weg, um ein signiertes öffentliches Release statt des Downloads von deiner Engine zu installieren. Du brauchst Bash, curl und OpenSSL mit Ed25519-Unterstützung, zum Beispiel OpenSSL 3 im PATH.

Checke das veröffentlichte öffentliche Release aus und prüfe es.
Führe im Checkout den Installer aus: bash bash scripts/install.sh

Das Skript installiert die passende CLI für Linux oder macOS und legt den lokalen subkit-Kompatibilitätslink an. Neben die CLI legt es subkit.LICENSE und subkit.THIRD_PARTY_NOTICES.txt. Die Release-Dateien müssen öffentlich herunterladbar sein. Ein lokaler Build oder ein privates Repository genügt nicht.

Was die Installer prüfen #

Jeder Installer prüft die Dateien, bevor er eine bestehende Installation ersetzt. Fehlende Lizenzdateien, fehlende Signaturen oder nicht unterstützte Kryptografie stoppen die Installation.

Installer	Was er prüft	Wem er vertraut
`scripts/install.sh`	Das signierte Prüfsummen-Manifest, danach die gewählte Binärdatei und beide Lizenzdateien	Dem festgelegten öffentlichen Release-Schlüssel
`/install` von der Engine	Die Binärdatei, `LICENSE` und `THIRD_PARTY_NOTICES.txt` aus demselben Engine-Bundle oder einem ausdrücklichen Mirror, gegen das Prüfsummen-Manifest dieser Quelle	Der gewählten Engine oder dem gewählten Mirror, nicht einer GitHub-Release-Signatur
GitHub-Updater	Beide signierten Lizenzdateien. Er aktualisiert die Hinweise neben der Binärdatei und behält die bestehenden mit ihren Prüfsummen für den Rollback.	Dem festgelegten öffentlichen Release-Schlüssel

Ältere behaltene Versionen ohne Hinweis-Metadaten können fehlende historische Lizenzdateien nicht rekonstruieren. Das Rollback dieser Versionen funktioniert weiter wie bisher.

Wenn etwas nicht klappt #

Was du siehst	Was du tust
`sk: browser login failed`	Die Anmeldung im Browser ist nicht abgeschlossen. Versuche es erneut oder folge „Mit einem API-Schlüssel anmelden“.
`sk login` erreicht die Engine nicht	Prüfe die `--engine-url`. Gib die Adresse ohne Pfad an.
`scripts/install.sh` stoppt wegen einer fehlenden Lizenzdatei oder Signatur	Nutze ein veröffentlichtes öffentliches Release. Ein lokaler Build oder ein privates Repository funktioniert nicht.
`scripts/install.sh` stoppt wegen nicht unterstützter Kryptografie	Stelle OpenSSL mit Ed25519-Unterstützung, zum Beispiel OpenSSL 3, in den PATH.