dadamsuk/slipdock

Slipdock CLI

Der Befehl slipdock kommuniziert mit der Slipdock-App des Benutzers – gehostet unter app.slipdock.us oder selbst gehostet unter der von ihm erreichten Adresse. Jeder Schreibvorgang wird live in der Weboberfläche angezeigt. Führe slipdock --help für die vollständige Referenz aus.

Welcher Server. $SLIPDOCK_URL, sonst ~/.config/slipdock/url (geschrieben von slipdock url <adresse> oder vom eigenen /install.sh des Servers), sonst die Tailnet-Adresse dieses Rechners auf :4000. Wenn keiner von diesen das Board ist, das der Benutzer meint, frage ihn nach der Adresse – rate nicht.

Wenn du im Begriff bist, vom Board aus zu arbeiten – die nächste Aufgabe aufnehmen, ein Epic durcharbeiten, Karten während der Arbeit aktualisieren – führe zuerst slipdock guide aus (die eigenen Anweisungen des Servers für Agenten: Epics und Unterkarten, wie die nächste Karte ausgewählt wird, was zurückgeschrieben werden soll) und folge ihnen. Diese Datei ist die Befehlsreferenz; der Guide ist der Workflow.

Wenn die MCP-Tools von Slipdock verbunden sind

Wenn diese Sitzung bereits Slipdock-Tools (list_boards, get_card, create_card, complete_card…, vom /mcp des Servers) hat, sind sie eine Alternative zum CLI für die gleiche Arbeit: Verwende, was vorhanden ist. Die Konventionen sind in beiden Fällen gleich – get_guide gibt die Kurzform des Guides zurück, den slipdock guide ausgibt, endend mit den Namen seiner anderen Abschnitte; section: "automations" (oder einer dieser Namen oder "all") gibt einen aus. archive_card legt eine Karte beiseite, und restore: true holt sie zurück; archive_board macht dasselbe für ein Board. Bevorzuge diese: delete_card (benötigt confirm: true), delete_list und delete_board (confirm ist der Code des Boards) können nicht rückgängig gemacht werden. create_list, create_tag und create_board fügen Struktur hinzu (ein Tag muss existieren, bevor create_card/update_card ihn auf eine Karte setzen kann). list_cards mit full: true liest jede Karte vollständig (Kommentare, Checkliste, Dokumente) in einem Aufruf, anstatt jedes Mal ein get_card durchzuführen. update_card setzt auch Abhängigkeiten und bearbeitet die Checkliste. list_pages listet das Wiki eines Boards auf (tree: true verschachtelt es, wie page tree), und read_page liest eine aus. page_info beantwortet, was page links, page sections, page wanted und page resolve tun – frage es nach sections vor einer write_page-Abschnittsbearbeitung, anstatt den Überschriftenpfad zu erraten. page_history ist page history und page diff (rev, rev + against zum Vergleich zweier Versionen oder diff: true für den letzten Speichervorgang), und revert_page ist page revert: es benötigt den aktuellen content_hash der Seite als base_hash. update_page ist page edit --title/--summary/--tag, page mv, page file, page rm/page restore (archived) und page pin --card (pin_card/unpin_card). upload_file ist attach für eine Datei von bis zu 10 MB (content_base64 oder text). Base64, das ein Modell ausschreibt, wird oberhalb von etwa 1 KB fehlerhaft (#1040), also sende es nicht, wenn eine Shell mit der Datei vorhanden ist: slipdock attach oder upload_file mit card/page und link: true (#1147), was mit einer einmaligen upload_url antwortet, die 10 Minuten gültig ist und kein Token benötigt, für curl -F file=@DATEI -F sha256=<hex> <upload_url> (auch filename, replace, hide_on_card), hält die Bytes aus dem Modell heraus. download_file mit link: true ist dasselbe in die andere Richtung: curl -fsSo DATEI <download_url>. Eine Datei, die sich bereits im synchronisierten Wiki des Benutzers befindet, wird vom Server mit wiki_file kopiert (ihr Pfad in deinem Wiki oder ihre ID; kein Inhalt). content_base64 muss sha256 enthalten (hexadezimal, von den Bytes vor Base64), und eine sha256_mismatch-Ablehnung bedeutet, erneut zu kodieren und zu senden. Das sha256 in der Antwort stammt von den Bytes wie gespeichert, und get_card/read_page listen es für jede Datei auf: Vergleiche das mit dem Hash der Quelle, um eine Datei zu verifizieren, anstatt sie herunterzuladen. Alles über ein paar KB wird in Chunks von etwa 4 KB gesendet (#1016), da die Wahrscheinlichkeit von Schäden bei längerem Base64 steigt: Der erste mit append: true, card/page, filename und dem sha256 dieses Chunks gibt eine upload_id zurück; jeder nächste sendet upload_id, append: true, offset (das received der letzten Antwort) und sein eigenes sha256, und ein abgelehnter Chunk wird einzeln erneut gesendet; dann macht upload_id, finish: true und das sha256 der gesamten Datei den Anhang. Nichts wird auf der Karte angezeigt, bevor das abgeschlossen ist. Ein Neuerstellen einer bereits auf der Karte befindlichen Datei sendet replace: true (beim einzelnen Aufruf, dem ersten Chunk oder finish): Ältere Dateien dieses Dateinamens werden entfernt, sobald die neue gespeichert ist, sodass eine aktuelle Kopie übrig bleibt. delete_attachment (detach; attachment-ID und confirm: true) entfernt eine vollständig, z. B. eine Datei, die du falsch hochgeladen hast. Und download_file liest eine angehängte Datei anhand ihrer ID (get_card und read_page listen sie auf). list_automations ist automations/automation (vocabulary: true fügt hinzu, was automation-help und automation-presets geben), und manage_automation ist new-automation (action: create), set-automation (update) und delete-automation (delete, mit confirm: true). list_tools ist tools/tools show (die Art jedes Tools und installed.board, das Board, das deine Installation erstellt hat; mit file, tools file; skill liest seine SKILL.md; link: true gibt eine einmalige download_url für die Datei, das Skill-Zip oder das Skills-Tarball, #1158; package: true, tools download), und install_tool ist tools install-board. Alles, was die Tools nicht abdecken (Ausführen einer Regel jetzt, Callbacks und Alerts, Sprints, Dateien über 10 MB, Felder), ist weiterhin das CLI oder die API.

Wenn das CLI hier nicht installiert ist

Alles unten ist ein Wrapper um eine JSON-API, und die API ist der Fallback: Sie benötigt nichts außer curl. Sage dem Benutzer nicht, das CLI zu installieren (es ist ein Escript und benötigt Erlang) – verwende die API und erwähne das CLI nur, wenn er nach etwas Fragt, das sich angenehmer tippen lässt, oder nach der Wiki-Synchronisation, die nur das CLI durchführt. Unter Windows ist das eine Zeile in PowerShell, von ihrem eigenen Server: irm "$B/cli/install.ps1" | iex, dann slipdock auth. Ansonsten wird es aus dem cli/-Verzeichnis des Repositorys erstellt.

B="${SLIPDOCK_URL:-$(cat ~/.config/slipdock/url 2>/dev/null)}"
T="$(cat ~/.config/slipdock/token 2>/dev/null)"
H="Authorization: Bearer ${SLIPDOCK_TOKEN:-$T}"

curl -s "$B/api/guide"                 # kein Token nötig; die gesamte API, mit curl für jeden Aufruf
curl -s -H "$H" "$B/api/me"            # wer das Token ist

GET /api/guide ist die vollständige Referenz – jeder Endpunkt mit einer curl-Zeile dafür, plus die eigenen Boards und Listen des Benutzers, wenn ein Token übergeben wird. Lies sie, anstatt Pfade aus dieser Datei abzuleiten.

Das Anmelden benötigt ebenfalls kein CLI; es ist derselbe Device-Flow, zwei Aufrufe (der Guide erklärt sie). Frage nach einem Code, zeige dem Benutzer die URL und den Code, warte, bis er zustimmt, und schreibe dann das Token in ~/.config/slipdock/token mit Modus 600, damit die nächste Sitzung es hat:

curl -s -X POST "$B/api/auth/device" -H 'content-type: application/json' \
     -d '{"label":"claude on this machine","scope":"write"}'
# → user_code, verification_uri, device_code, interval
curl -s -X POST "$B/api/auth/device/token" -H 'content-type: application/json' \
     -d '{"device_code":"…"}'
# → 400 authorization_pending bis zur Zustimmung, dann {"token":"…"}

Um diese Skills auf einem Rechner zu installieren, der keinen davon hat: curl -fsSL "$B/install.sh" | sh (benötigt nur curl und tar); unter Windows, in PowerShell: irm "$B/install.ps1" | iex (in %USERPROFILE%\.claude\skills, nicht in WSLs Home). Für ChatGPT, das dieses CLI nicht ausführen kann, speichert slipdock skills chatgpt sie als Zips zum Hochladen, wobei jedes die Befehle auf die Tools des MCP-Connectors abbildet ($B/api/skills/<name>/chatgpt.zip).

Anmelden

Die API benötigt ein Token. Wenn ein Befehl mit not signed in fehlschlägt, führe slipdock auth aus – es gibt einen kurzen Code und eine URL aus, der Benutzer genehmigt ihn in einem Browser, in dem er bereits angemeldet ist, und du hast wenige Sekunden später ein Token. Sage ihm den Code und die URL; bitte ihn nicht, manuell ein Token zu erstellen, es sei denn, er möchte es lieber (slipdock auth <token> akzeptiert immer noch eines, und SLIPDOCK_TOKEN funktioniert weiterhin).

slipdock whoami zeigt den aktuellen Benutzer. Boards, auf die der Benutzer nicht zugreifen kann, werden einfach nicht aufgelistet; ein forbidden-Fehler bedeutet, dass er etwas sehen, aber nicht ändern kann. Zwei Ablehnungen nennen das Token anstelle des Benutzers und bedeuten, dass das gehaltene Token bewusst eingeschränkt ist, anstatt dass etwas kaputt ist – sage das, anstatt es erneut zu versuchen:

• this API token is read-only – es wurde nur mit Lesezugriff gewährt. Frage nach einem Lese-/Schreib-Token.
• this API token's scope doesn't allow it – es ist auf bestimmte Boards beschränkt, oder es ist kein Admin-Token, und du hast versucht, den Server zu verwalten.

Zwei weitere Ablehnungen sind ebenfalls endgültig. Melde sie und sage, was die Person tun kann:

• card_limit_reached (HTTP 402) – das Konto des Board-Besitzers hat alle Items aufgebraucht, die es erlaubt. Ein Item ist eine Karte, eine Wiki-Seite oder eine hochgeladene Datei: Alle drei zählen gegen eine Zahl, daher hilft es nicht, es stattdessen als Seite zu schreiben. Ein anderer Titel hilft ebenfalls nicht; es wird auf die gleiche Weise fehlschlagen, für immer. Empfehle, etwas Erledigtes zu archivieren. slipdock whoami --json und slipdock guide geben beide an, wie viel vom Kontingent noch übrig ist, sodass du vor dem Start einer Batch-Verarbeitung überprüfen kannst, anstatt die Grenze mittendrin zu entdecken.
• board_limit_reached (HTTP 402) – sie besitzen so viele Boards, wie dieser Server einer Person erlaubt. Unterboards (Unterkarten) zählen nicht dazu. Empfehle, ein Board zu archivieren oder einen Admin zu fragen.
• storage_limit_reached (HTTP 402) – ihre hochgeladenen Dateien füllen den erlaubten Speicherplatz. Nur das Löschen von Anhängen gibt Speicher frei; das Archivieren der Karte, an der die Datei hängt, tut dies nicht.
• trial_expired (HTTP 402) – eine kostenlose Testversion ist abgelaufen. Es kann nichts Neues mehr auf ihren Boards hinzugefügt werden, egal wie klein. Alles, was bereits vorhanden ist, bleibt lesbar und bearbeitbar. Du kannst nichts dagegen tun: Sage der Person, dass sie ein Abonnement abschließen muss, und höre auf. Diese vier betreffen mehr als das Erstellen: eine Wiederherstellung aus dem Archiv, move --board auf das Board einer anderen Person (die Karte und alles darunter zählt gegen sie), einen Import und welcome.
• No account here uses that address… beim Teilen – dieser Server erstellt keine Konten für die Personen, mit denen du Dinge teilst. Ein Admin muss sie einladen.

Auf einem Server, auf dem Personen nur diejenigen sehen, mit denen sie etwas teilen, wurde jemand, den du erwartest zu finden und nicht finden kannst, wahrscheinlich nichts geteilt. Sie wurden nicht gelöscht, und das Zuweisen einer Karte zu ihnen wird nicht funktionieren, bis etwas geteilt wird.

Eine Karte kann nur jemandem zugewiesen werden, der sie öffnen kann. user … not found bei einem Zugewiesenen bedeutet genau das, unabhängig davon, ob sie ein Konto haben – teile zuerst das Board mit ihnen (die Teilen-Einstellungen des Boards im Browser) oder frage die Person danach.

Workflow

1. Finde zuerst das Board und seine Struktur: slipdock boards, dann slipdock board <board> oder slipdock columns <board> und slipdock tags <board>. Boards und Spalten akzeptieren eine ID oder einen Namen ohne Berücksichtigung der Groß-/Kleinschreibung, also funktioniert slipdock board "product launch". Jedes Board hat auch einen Code – seinen Kurznamen: eindeutig, URL-sicher, maximal 10 Zeichen, abgeleitet vom Namen des Boards und bearbeitbar ("QVM V1 Remediation" ist qvm-v1-rem). Er steht in der CODE-Spalte von slipdock boards und im code-Feld von --json, und <board> akzeptiert ihn überall: slipdock board qvm-v1-rem, slipdock add qvm-v1-rem "...". Bevorzuge ihn gegenüber dem Namen – er ist eindeutig und überlebt Umbenennungen – und verwende ihn, wenn du ein Board an den Benutzer zurückmeldest. slipdock new-board <name> [--code C] setzt einen explizit; wenn weggelassen, wird einer aus dem Namen generiert. Ein Board hat auch eine Shortcut-Taste – ein oder zwei Zeichen, die im Web-App zu ihm springen (drücke b, dann die Taste). Sie ist die KEY-Spalte von slipdock boards und das shortcut-Feld von --json, und sie wird mit --shortcut K bei new-board oder set-board gesetzt. Sie ist keine Möglichkeit, ein Board über die Kommandozeile anzusprechen; der Code ist es.
2. Lies, bevor du schreibst. slipdock card <id> zeigt alles: Beschreibung, Flaggen, Tags, IDs von Checklistenelementen, Kommentare.
3. Verwende --json, wenn du die Ausgabe parsen musst (IDs, Filtern, Zählen). Die einfache Ausgabe ist zum Anzeigen für den Benutzer.
4. Bevorzuge archive gegenüber delete. Löschen ist endgültig. Frage, bevor du etwas löschst, das der Benutzer nicht explizit zu löschen verlangt hat. Ein gesamtes Board kann ebenfalls archiviert werden (slipdock archive-board <board>), was nicht dasselbe ist wie das Archivieren einer Karte und viel weiter von deinem Geschäft entfernt ist: Es entfernt das Board aus dem Index, dem Board-Switcher und dem Schnellhinzufügen des Benutzers. Archiviere oder ordne ein Board niemals neu an, es sei denn, der Benutzer hat nach diesem Board mit Namen gefragt.
5. Sage, was passiert, während es passiert. Arbeiten, die länger als eine kurze Sitzung dauern, erhalten slipdock comment <id> ... bei jedem Meilenstein – und slipdock edit <id> --percent N passend – anstatt einer Zusammenfassung am Ende. Eine Karte in Bearbeitung ohne neueren Kommentar als die Verschiebung wird von den Beobachtern als aufgegeben gelesen.
6. Melde IDs an den Benutzer zurück (#42), damit er Karten in der Benutzeroberfläche finden kann. @handle (E-Mail einer Person vor dem "@") in einem Kommentar oder einer Beschreibung sendet dieser Person eine E-Mail.