OpenDocs – Markdown als teilbare URLs und PDF/DOCX veröffentlichen
OpenDocs verwandelt jede Markdown-Datei in eine saubere, lesbare URL – und im selben Workflow in ein gebrandetes PDF- oder Word-Dokument, wenn der Benutzer eine Datei zum Offline-Teilen wünscht. Sie interagieren damit über die opendocs-CLI.
Kurzreferenz
opendocs login --email [email protected] # Anmelden oder Registrieren: sendet einen 6-stelligen Code per E-Mail
opendocs login --email [email protected] --code 123456 # Abschließen: speichert einen API-Key für Sie
opendocs login --browser # Benutzerfreundliches Browser-Login
opendocs login --key od_live_xxxxx # Vorhandener API-Key
opendocs publish doc.md # Eine Markdown-Datei veröffentlichen → URL erhalten
opendocs publish doc.md # ... erneut: aktualisiert dasselbe Dokument (kein Duplikat)
opendocs publish doc.md --anonymous # Kein Konto: ein Link, den jeder 24 Stunden öffnen kann + URL beanspruchen
opendocs clone # Arbeitsbereich in ./<workspace> herunterladen, um zu bearbeiten
opendocs status # Was sich lokal / online seit letzter Synchronisation geändert hat
opendocs history <doc> # Jede veröffentlichte Version
opendocs rollback <doc> <version> # Eine Version wiederherstellen (als neue Version)
opendocs move <doc> --project "Archiv" # Zwischen Projekten verschieben
opendocs share <doc> [email protected] @acme.com # Personen außerhalb des Arbeitsbereichs Zugriff geben
opendocs team invite [email protected] # Ein Teammitglied einladen (es akzeptiert per E-Mail)
opendocs team join # Eine Einladung annehmen, die Ihnen geschickt wurde
opendocs theme # Markenfarbe, Schriftart, Logo und Fußzeile für PDF/DOCX-Exporte
opendocs theme set --preset editorial --yes # Ändert das Export-Theme (fragen Sie zuerst Ihren Menschen)
opendocs integrations # Google Drive / DocuSeal: was verbunden ist, benannte Drive-Ordner
opendocs save <doc> --folder "Sitzungsprotokolle" # Ein PDF (oder --format docx|md) in einem benannten Drive-Ordner speichern
opendocs sign request <doc> --signer "Mitarbeiter=John Adams <[email protected]>" # Signaturanfrage entwerfen (sendet nichts)
opendocs sign send <id> --yes # Den Entwurf senden, erst nachdem der Benutzer jeden Unterzeichner bestätigt hat
opendocs sign status <id> # Wer unterschrieben hat; auch Liste anzeigen / herunterladen / speichern / stornieren
opendocs workspace create "Acme Forschung" # Neuen Arbeitsbereich erstellen
opendocs project link "Acme Launch" # Aus diesem Ordner veröffentlichte Dokumente gehen in dieses Projekt
opendocs config set organize auto # Agenten Dokumente ohne Nachfrage in Projekte sortieren lassen
opendocs claim # Anonyme Dokumente aus diesem Ordner behalten
opendocs publish *.md # Mehrere Dateien veröffentlichen (automatisch gebündelt, bis zu 500)
opendocs publish ./vault --tags obsidian # Einen Ordner/Vault rekursiv veröffentlichen
opendocs publish *.md --export pdf # Veröffentlichen UND exportieren – PDFs landen neben jeder Quelldatei
opendocs update doc.md --post-id <id|slug> # Einen bestehenden Beitrag aktualisieren (neue Version)
opendocs list # Dokumente im aktiven Arbeitsbereich auflisten (Alias: `opendocs ls`)
opendocs list --all # Über alle Arbeitsbereiche hinweg auflisten, denen Sie angehören
opendocs project create <name> --use # Ein Projekt für eine zusammenhängende Dokumentsammlung erstellen/wechseln
opendocs project use <slug> # Aktives Projekt wechseln
opendocs list --tag <tag> # Nach Tag filtern (ideal zum Finden einer Sammlung)
opendocs search <wörter> # Dokumente nach Titel oder Zusammenfassung in jedem Projekt finden
opendocs get <id|slug> # Beitragsdetails anzeigen
opendocs pull <id|slug> # Rohes Markdown herunterladen
opendocs pull --project # Jedes Dokument im aktiven Projekt herunterladen
opendocs pull --workspace # Jedes Dokument im aktiven Arbeitsbereich herunterladen
opendocs export <id|slug> --format pdf # Einen veröffentlichten Beitrag als PDF (oder docx) exportieren
opendocs export a b c --format pdf # Bis zu 10 Beiträge gleichzeitig exportieren (UUIDs oder Slugs)
opendocs unpublish <id|slug> # Einen Beitrag offline nehmen (Inhalt und Verlauf bleiben; keine erneute Veröffentlichung)
opendocs visibility <id|slug> <level> # Sichtbarkeit ändern, ohne Markdown erneut hochzuladen
opendocs delete <id|slug> --yes # Beitrag endgültig löschen (gibt Slug + Kontingentslot frei)
opendocs whoami # Aktuellen Benutzer/Arbeitsbereich/Projekt anzeigen
opendocs workspace list # Alle Arbeitsbereiche auflisten, denen Sie angehören (Alias: `workspace ls`)
opendocs workspace use <slug> # Aktiven Arbeitsbereich wechseln (Alias: `workspace switch`)
opendocs agent # Kurze KI-Agenten-Anleitung ausgeben
opendocs agent --full # Vollständiges gebündeltes SKILL.md ausgeben
opendocs agent --install # Dieses Skill für jeden Agenten auf diesem Rechner installieren
opendocs mcp add # OpenDocs-MCP-Server in Ihren Codierungstools registrieren
opendocs mcp connect claude # OpenDocs zur Claude-App hinzufügen (oder: chatgpt)
opendocs logout # Gespeicherte Anmeldeinformationen löschen
Jeder Befehl akzeptiert --json für maschinenlesbare Ausgabe und --api-url <url> zum Überschreiben des API-Endpunkts. Bei programmatischer Ausführung immer --json übergeben – stdout wird ein einzelnes analysierbares JSON-Objekt, Fehler gehen an stderr und menschenlesbare Ladebalken werden unterdrückt.
Jeder Befehl, der ein <postId> erwartet, akzeptiert auch einen Slug. Der Slug ist das menschenlesbare Pfadsegment des Beitrags in der URL und innerhalb des aktiven Projekts eindeutig. Bevorzugen Sie Post-Slugs, wenn der Benutzer ein Dokument in natürlicher Sprache nennt: opendocs get my-report ist freundlicher, als die UUID aus opendocs list --json zu kopieren. Intern löst die API den Slug über eine indizierte Suche im aktiven Arbeitsbereich/Projekt auf und führt dann dieselbe Eigentümerprüfung wie der UUID-Pfad durch.
Arbeitsbereich-Slug vs. Benutzername – das sind unterschiedliche Dinge. Die URL wird aus dem Arbeitsbereichs-Slug aufgebaut, nicht aus dem Benutzernamen des Benutzers. Standardprojektdokumente verwenden opendocs.cc/<workspace>/<post>. Nicht-Standardprojektdokumente verwenden opendocs.cc/<workspace>/projects/<project>/<post>. Der Benutzername existiert weiterhin für die Zuordnung in der Benutzeroberfläche, erscheint aber nicht in veröffentlichten URLs.
OpenDocs über MCP
OpenDocs betreibt auch einen Remote-MCP-Server unter https://mcp.opendocs.cc/mcp (Anleitung: https://opendocs.cc/mcp). Jede App meldet den Benutzer bei der ersten Nutzung mit OAuth bei OpenDocs an; es ist kein API-Key erforderlich.
- Chat-Apps (Claude, ChatGPT): Fügen Sie es als benutzerdefinierten Connector mit dieser URL hinzu.
opendocs mcp connect claudeöffnet Claudes Dialog „Benutzerdefinierten Connector hinzufügen“ mit ausgefüllter OpenDocs.cc-URL;opendocs mcp connect chatgptöffnet die ChatGPT-Plugins-Seite (dann „+" → „Benutzerdefinierten MCP-Server hinzufügen"). Beide kopieren die URL in die Zwischenablage. - Codierungstools:
opendocs mcp addregistriert es in jedem Tool, das es findet (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini, opencode, Kiro) und gibt eine einzeilige Anweisung für die anderen aus.--agent <id...>wählt Tools aus,--dry-runzeigt, was sich ändern würde,opendocs mcp removeentfernt es wieder, undopendocs agent --install --mcpinstalliert dieses Skill und den Server zusammen. - MCP-Tools oder die CLI? Wenn OpenDocs-MCP-Tools verfügbar sind und Sie keine Shell-Befehle ausführen können, verwenden Sie diese anstelle der CLI; sie nehmen Markdown-Text direkt entgegen. Wenn Sie eine Shell haben, bevorzugen Sie die CLI für lokale Dateien, Ordner und Bilder: Sie lädt lokale Bilder hoch, veröffentlicht ganze Ordner in Batches und merkt sich, was jeder Ordner veröffentlicht hat.
Einrichtung
Installation
Möglichkeiten, OpenDocs in einen Agenten zu bekommen:
# Node.js 20+: die vollständige CLI (empfohlen), dann dieses Skill für jeden gefundenen Agenten
npm install -g @opendocs.cc/cli
opendocs agent --install # SKILL.md + scripts/opendocs.sh, keine Netzwerkverbindung erforderlich
# Node.js 22+: dasselbe Skill über die Skills-CLI
npx skills add opendocs-cc/skills --skill opendocs -g -y
# Kein Node.js: installiert dieses Skill + scripts/opendocs.sh (curl + jq)
curl -fsSL https://opendocs.cc/install.sh | bash
opendocs agent --install installiert in den globalen Skills-Ordner jedes Agenten, dessen Konfigurationsordner existiert: ~/.claude/skills (Claude Code), der gemeinsame ~/.agents/skills (Codex, Cursor, GitHub Copilot, Gemini CLI, opencode, OpenClaw, Windsurf, Amp, Goose, Grok Build), ~/.cline/skills, ~/.hermes/skills und ~/.kiro/skills. opendocs agent --list zeigt jeden Agentenordner und ob er gefunden wurde; --agent <id...> installiert für bestimmte Agenten, auch wenn sie nicht gefunden wurden (--agent claude-code codex). Führen Sie es nach einem CLI-Update erneut aus, um das Skill zu aktualisieren. Es gibt aus, in welche Ordner es geschrieben hat; mit --json hat installed[] die Felder agent, path und status.
In Claude Code können Sie es auch als OpenDocs.cc-Plugin installieren, das /opendocs-cc:publish und /opendocs-cc:export hinzufügt, den MCP-Server verbindet und das Skill auf dem neuesten Stand hält: /plugin marketplace add opendocs-cc/skills, dann /plugin install opendocs-cc@opendocs-cc. In Codex: codex plugin marketplace add opendocs-cc/skills, dann codex plugin add opendocs-cc@opendocs-cc.
npx skills add kann mit ✗ opendocs → PromptScript: PromptScript does not support global skill installation enden. Das ist ein bekannter Installationsfehler, der nur PromptScript betrifft; das Skill ist installiert, also fahren Sie fort.
Wenn der opendocs-Befehl nicht verfügbar ist und Node.js nicht installiert ist, verwenden Sie stattdessen bash scripts/opendocs.sh (im Ordner dieses Skills) – siehe „Ohne Node.js" unten. Alles andere in dieser Anleitung gilt für beide.
Prüfen, ob die CLI installiert und authentifiziert ist
opendocs --version # Gibt die installierte CLI-Version aus
opendocs whoami # Zeigt Benutzername + Arbeitsbereichsname an (der URL-Slug lebt in der JSON-Ausgabe)
opendocs whoami --json ist der nützlichste Diagnosebefehl für einen Agenten – er gibt den aktiven Arbeitsbereich-Slug der CLI (zum Erstellen von Beitrags-URLs) sowie den Konto-/Arbeitsbereichskontext und das Dokumentenkontingent in einem Aufruf zurück:
{
"userId": "...",
"onboarding": { "username": "...", "workspace": { "id": "...", "name": "Acme Docs", "slug": "acme-docs" } },
"quota": { "documents": { "plan": "free", "limit": 50, "used": 3, "remaining": 47 } }
}
Für Pro/Team-Arbeitsbereiche sind quota.documents.limit und remaining null (bedeutet unbegrenzt). Die Veröffentlichungs-Endpunkte überprüfen das Kontingent dennoch anhand der expliziten workspaceId im Anforderungstext, sodass eine veraltete lokale Konfiguration die Serverdurchsetzung nicht umgehen kann.
Wenn die CLI fehlt:
npm install -g @opendocs.cc/cli
Wenn der Benutzer nicht angemeldet ist, melden Sie ihn vor seiner ersten Veröffentlichung an (oder registrieren Sie ihn) über das Terminal mit einem per E-Mail gesendeten Code: kein Browser, kein Kopieren von API-Keys. Ein Konto ist für bis zu 50 Dokumente kostenlos und ist das, was der Benutzer standardmäßig möchte: Links bleiben bestehen, bleiben privat für seinen Arbeitsbereich, können direkt aktualisiert und als PDF exportiert werden.
- Fragen Sie den Benutzer nach seiner E-Mail-Adresse.
- Führen Sie
opendocs login --email <email> --jsonaus. Es sendet einen 6-stelligen Code per E-Mail und beendet sich sofort mit{"status": "code_sent", ...}. - Sagen Sie dem Benutzer: „Überprüfen Sie Ihren Posteingang auf einen Anmeldecode von OpenDocs und fügen Sie ihn hier ein."
- Führen Sie
opendocs login --email <email> --code <code> --jsonaus.
Wenn die E-Mail neu ist, erstellt dies das Konto, einen Benutzernamen, einen Arbeitsbereich (opendocs.cc/<username>) und ein Standardprojekt und speichert dann einen neuen API-Key mit dem Namen Ihres Agenten (z. B. claude-code) in der CLI-Konfiguration. Vorhandene Konten erhalten nur einen neuen Key. opendocs signup ist ein Alias. Codes laufen nach 10 Minuten ab und erlauben 5 Versuche; bei invalid_code fragen Sie nach der neuesten E-Mail, bei code_expired führen Sie Schritt 2 erneut aus.
Nur wenn der Benutzer noch kein Konto möchte, bieten Sie stattdessen eine anonyme Veröffentlichung an:
opendocs publish notes.md --anonymous --json
Jeder mit der zurückgegebenen url kann sie 24 Stunden lang lesen, dann wird sie gelöscht. Teilen Sie dem Benutzer den claimUrl genau wie zurückgegeben mit und bieten Sie an, ihn anzumelden, damit er gespeichert wird: Das spätere Ausführen von opendocs login --email ... vom selben Ordner aus beansprucht es automatisch in seinem neuen Arbeitsbereich (oder führen Sie opendocs claim aus). Veröffentlichen Sie niemals anonym, es sei denn, der Benutzer hat zugestimmt, dass ein Link, den jeder öffnen kann, in Ordnung ist.
Andere Anmeldemethoden: Menschen an einem Terminal können opendocs login --browser verwenden; Skripte und CI können einen vorhandenen Key verwenden:
opendocs login --key od_live_xxxxx
# Oder über Umgebungsvariable für Skripte / CI übergeben:
export OPENDOCS_API_KEY=od_live_xxxxx && opendocs login
Führen Sie niemals ein bloßes opendocs login von einem Agenten aus. Ohne --email, --key oder die Umgebungsvariable fordert es zur Eingabe eines API-Keys auf stdin auf und Ihr Tool-Aufruf hängt. OPENDOCS_API_URL überschreibt den integrierten Endpunkt https://api.opendocs.cc.
Arbeiten mit mehreren Arbeitsbereichen
Ein Benutzer kann zu mehr als einem Arbeitsbereich gehören – ein persönlicher kostenloser Arbeitsbereich plus ein Team-Plan-Arbeitsbereich, mehrere Team-Arbeitsbereiche oder jede Mischung. Die CLI speichert jeweils einen aktiven Arbeitsbereich in ~/.config/opendocs/config.json. publish und update wirken auf diesen aktiven Arbeitsbereich (URL-Präfix, Kontingent und alles). list verwendet standardmäßig ebenfalls diesen, mit --all als Ausweichmöglichkeit, wenn der Benutzer alle Beiträge aller Arbeitsbereiche sehen möchte. Es gibt kein --workspace-Flag pro Aufruf bei mutierenden Befehlen; der Wechsel wird einmal konfiguriert und bleibt bestehen, bis Sie ihn ändern.
Arbeiten mit Projekten
Jeder Arbeitsbereich hat ein Standardprojekt plus optionale benannte Projekte. Verwenden Sie ein Projekt, wenn ein Agent eine zusammenhängende Sammlung von Dokumenten für ein Produkt, einen Launch, einen Kunden, ein Experiment oder ein Repository veröffentlicht. Das Standardprojekt eignet sich am besten für einmalige Dokumente.
opendocs project list --json
opendocs project create "OpenClaw-Dokumentation" --slug openclaw-docs --use --json
opendocs publish ./docs --json
opendocs project use default --json
opendocs workspace use <slug> setzt das aktive Projekt auf das Standardprojekt dieses Arbeitsbereichs zurück. opendocs list zeigt standardmäßig das aktive Projekt an und endet mit der Angabe, wie viele Dokumente
…
[gekürzt für die Übersetzung]