xdrop

Überblick über das xdrop skill

Was das xdrop skill macht

Das xdrop skill hilft einem Agenten dabei, lokale Dateien oder Verzeichnisse auf einen Xdrop-Server hochzuladen und Dateien über einen Xdrop-Freigabelink wieder herunterzuladen – inklusive lokaler Entschlüsselung bei verschlüsselten Übertragungen. Es eignet sich besonders für terminalgesteuerte Datei-Automatisierung, wenn Sie einen wiederholbaren Befehl, eine saubere Share-URL und optional maschinenlesbare Ausgabe brauchen.

Für wen sich die Installation des xdrop skill lohnt

Installieren Sie dieses xdrop skill, wenn Sie:

• Dateien über eine Xdrop-Instanz aus Skripten oder Agent-Workflows bewegen
• Xdrop-Links wie /t/<transferId>#k=... erhalten und lokal herunterladen sowie entschlüsseln möchten
• stabile CLI-Flags wie --json, --quiet, --output, --expires-in oder --api-url benötigen
• einen konkreten Upload-/Download-Weg wollen, statt rohe HTTP-Calls selbst zusammenzubauen

Welches konkrete Problem xdrop löst

Die meisten Nutzer suchen nicht abstrakt nach „einem File-Sharing-Skill“. Sie wollen zuverlässig einen von zwei Jobs automatisieren:

1. lokale Dateien im Terminal in einen Xdrop-Freigabelink umwandeln
2. einen vorhandenen Xdrop-Link nehmen und die Dateien lokal wiederherstellen, ohne das Protokoll erraten zu müssen

Genau hier ist xdrop nützlich: Das Skill bündelt den Ablauf in zwei direkt ausführbare Skripte, statt den Agenten das Share-Format rückwärts erschließen zu lassen.

Warum xdrop mehr bietet als ein generischer Prompt

Ein generischer Prompt kann beschreiben, wie Xdrop vermutlich funktioniert. Das xdrop skill liefert ausführbare Skripte, die den praktischen Pfad bereits abdecken:

• Upload über scripts/upload.mjs
• Share-Links parsen und herunterladen über scripts/download.mjs
• den erwarteten API-Root standardmäßig verwenden
• stille und JSON-Ausgabe für automatisierungsfreundliche Pipelines unterstützen

Wichtige Einschränkungen, die Sie vorab kennen sollten

Bevor Sie xdrop übernehmen, prüfen Sie diese Voraussetzungen:

• Zum Ausführen der mitgelieferten Skripte ist bun erforderlich
• der Agent braucht Zugriff auf das lokale Dateisystem
• der Agent braucht Netzwerkzugriff auf den Ziel-Xdrop-Server
• Uploads sind für Xdrop-kompatible Server gedacht, nicht für beliebige File-Hosts

Wenn Ihre Umgebung Bun nicht ausführen kann oder den Zielserver nicht erreicht, ist dieser xdrop-Leitfaden nicht der richtige Weg.

So verwenden Sie das xdrop skill

xdrop skill in Ihr Skills-Setup installieren

Wenn Sie das Skills-System verwenden, installieren Sie xdrop mit:

npx skills add https://github.com/xixu-me/skills --skill xdrop

Arbeiten Sie anschließend mit den Dateien im Skill-Verzeichnis:

• skills/xdrop/SKILL.md
• skills/xdrop/scripts/upload.mjs
• skills/xdrop/scripts/download.mjs

Laufzeitvoraussetzungen für die xdrop-Nutzung installieren

Das Skill selbst ist skriptbasiert, daher ist Bun die zentrale praktische Voraussetzung. Prüfen Sie vor der Nutzung von xdrop, ob Bun verfügbar ist:

bun --version

Vergewissern Sie sich außerdem, dass:

• Sie die lokalen Dateien lesen können, die Sie hochladen möchten
• Sie in das Zielverzeichnis für Downloads schreiben können
• der Xdrop-Server aus Ihrer Umgebung erreichbar ist

Diese Dateien sollten Sie zuerst lesen

Für eine schnelle Bewertung empfiehlt sich diese Reihenfolge:

1. SKILL.md für unterstützten Workflow und verfügbare Flags
2. scripts/upload.mjs für Upload-Argumente und Limits
3. scripts/download.mjs für Share-Link-Parsing und Ausgabeverhalten

Diese Lesereihenfolge reicht in der Regel aus, um zu entscheiden, ob xdrop für Datei-Automatisierung in Ihre Pipeline passt.

Die zwei zentralen Einstiegspunkte im xdrop skill verstehen

Das xdrop skill ist bewusst eng fokussiert. In der Praxis rufen Sie meist eines dieser beiden Skripte auf:

• Upload:

  bun scripts/upload.mjs --server <xdrop-site-url> <file-or-directory> [...]
  

• Download:

  bun scripts/download.mjs <share-url>
  

Dieser enge Zuschnitt ist ein Vorteil, wenn Sie verlässliche Dateiübertragungs-Automatisierung statt eines breiten SDKs suchen.

Dateien mit xdrop hochladen

Ein einfacher Upload sieht so aus:

bun scripts/upload.mjs --server http://localhost:8080 ./dist/report.pdf

Sie können auch mehrere Pfade gleichzeitig hochladen:

bun scripts/upload.mjs --server https://xdrop.example.com ./photo.jpg ./notes.txt

Nutzen Sie das, wenn das Ziel des Nutzers lautet: „Teile diese lokalen Dateien und gib mir einen Link“ – nicht wenn Funktionen wie Storage-Sync, Browsing oder Account-Management gebraucht werden.

Automatisierungsfreundliche Upload-Flags gezielt einsetzen

Die nützlichsten Flags für echte Automatisierung sind:

• --json für strukturierte Weiterverarbeitung
• --quiet für saubere stdout-Ausgabe
• --expires-in <sec> zur Steuerung der Gültigkeitsdauer des Transfers
• --name <value> zum Setzen eines Transfer-Labels
• --api-url <url>, wenn der API-Root nicht dem Standard entspricht
• --concurrency <n> zur Feinabstimmung paralleler Uploads

Beispiel:

bun scripts/upload.mjs \
  --server http://localhost:8080 \
  --expires-in 600 \
  --json \
  --quiet \
  ./notes.txt

Für Agent-Workflows ist --json besonders wichtig, weil Felder wie transferId, shareUrl und expiresAt zurückgegeben werden, statt fragiles Parsing von Klartextausgaben zu erzwingen.

Über einen Share-Link herunterladen und entschlüsseln

Der wichtigste Download-Fall ist eine vollständige Xdrop-Share-URL inklusive Key-Fragment:

bun scripts/download.mjs "http://localhost:8080/t/abc#k=..."

Das Skript parst den Share-Link, lädt die Transfer-Metadaten, lädt den verschlüsselten Inhalt herunter und entschlüsselt ihn lokal. Genau deshalb ist das xdrop skill einem handgeschriebenen Prompt vorzuziehen: Das Link-Format mit Schlüsselanteil wird bereits korrekt verarbeitet.

Download-Ausgabe sauber steuern

Standardmäßig landen Downloads in einem Verzeichnis wie ./xdrop-<transferId>. Überschreiben Sie das, wenn Ihr Workflow einen festen Pfad erwartet:

bun scripts/download.mjs --output ./downloads "http://localhost:8080/t/abc#k=..."

Nützliche Flags:

• --output <dir> für deterministische Dateiplatzierung
• --json für maschinenlesbare Ergebnis-Ausgabe
• --quiet für sauberere Logs
• --api-url <url>, wenn sich der API-Root von <share-origin>/api/v1 unterscheidet

Aus einer vagen Absicht einen guten xdrop-Prompt machen

Schwache Anfrage:

upload this file to xdrop

Bessere Anfrage:

Use the xdrop skill to upload ./build/app.tar.gz to https://xdrop.example.com, set expiry to 600 seconds, return JSON only, and keep stdout quiet.

Schwache Anfrage:

fetch this xdrop link

Bessere Anfrage:

Use xdrop to download https://xdrop.example.com/t/abc#k=..., save it under ./artifacts/incoming, and return the output path as JSON.

Gute Prompts für die xdrop-Nutzung enthalten:

• die Server-URL oder die vollständige Share-URL
• exakte lokale Dateipfade
• das gewünschte Ausgabeverzeichnis
• ob die Ausgabe Klartext oder JSON sein soll
• Anforderungen an die Ablaufzeit bei Uploads

Bester Workflow für xdrop in der Datei-Automatisierung

Ein praxistauglicher Workflow ist:

1. Bun und Netzwerkzugriff prüfen
2. zuerst mit einer kleinen Datei testen
3. auf --json umstellen, sobald der Befehl funktioniert
4. --quiet hinzufügen, wenn ein anderes Skript oder ein Agent stdout parsen soll
5. erst danach größere oder mehrere Dateien übertragen

So sparen Sie Debugging-Zeit, weil die meisten Fehler aus der Umgebung, aus falschen Pfaden oder aus fehlender Server-Erreichbarkeit kommen – nicht aus der Transferlogik selbst.

Praktische Grenzen und Abwägungen

Den Signalen aus den Skripten nach ist xdrop für geradlinige Transfers optimiert, nicht für unbegrenzte Bulk-Bewegung. Das Upload-Skript definiert:

• maximale Parallelität begrenzt auf 6
• eine maximale Transfergröße von 256 * 1024 * 1024 Bytes

Damit eignet sich dieser xdrop-Leitfaden besser für kurzlebiges Teilen und Automatisierungsaufgaben als für sehr große Archiv-Workflows.

FAQ zum xdrop skill

Ist das xdrop skill anfängerfreundlich

Ja, sofern Sie sich damit wohlfühlen, Bun-Skripte im Terminal auszuführen. Die Oberfläche ist einfach, aber Einsteiger brauchen oft dennoch Hilfe bei:

• der Installation von Bun
• der Übergabe korrekter Dateisystempfade
• dem Verständnis des Unterschieds zwischen Site-URL und API-URL
• dem Erhalt des #k=...-Fragments in einem Share-Link

Wann ist xdrop besser als ein normaler Prompt

Das xdrop skill ist besser, wenn Ausführung statt Erklärung gefragt ist. Ein normaler Prompt kann Xdrop beschreiben, aber dieses Skill liefert einen konkreten Upload-/Download-Weg mit den richtigen Flags und bereits eingebautem Workflow für lokale Entschlüsselung.

Welche Eingaben braucht xdrop von mir

Für Uploads:

• eine öffentliche Xdrop-Site-URL über --server
• einen oder mehrere lokale Datei- oder Verzeichnispfade

Für Downloads:

• eine vollständige Share-URL, idealerweise inklusive Key-Fragment
• optional ein Ausgabeverzeichnis und ein API-Override

Ohne diese Angaben muss ein Agent raten – und die Qualität der xdrop-Nutzung sinkt schnell.

Brauche ich für den Download die vollständige Share-URL

Ja, in der Praxis sollten Sie den vollständigen Xdrop-Link angeben. Das Download-Skript erwartet ausdrücklich einen kompletten Share-Link und leitet daraus Transfer-ID, Origin und Schlüsselmaterial ab. Eine bloße Transfer-ID reicht für den vollständigen lokalen Entschlüsselungsablauf nicht aus.

Eignet sich xdrop für CI oder skriptgesteuerte Pipelines

Ja. Das ist einer der besten Gründe, xdrop zu installieren. Die Unterstützung für --json und --quiet macht das Skill gut geeignet für Shell-Skripte, CI-Jobs und Agent-Ketten, in denen stdout parsbar bleiben muss.

Wann sollte ich xdrop nicht verwenden

Verzichten Sie auf xdrop, wenn:

• Sie Bun nicht ausführen können
• Sie eine Browser-first-UX statt Terminal-Automatisierung benötigen
• Sie Funktionen jenseits von Upload-/Download-Automatisierung brauchen
• Ihr Ziel kein Xdrop-kompatibler Server ist
• Ihr Workflow Dateien oberhalb der vorgesehenen Transfergrenzen umfasst

So verbessern Sie das xdrop skill

xdrop mit vollständigen, eindeutigen Eingaben versorgen

Der schnellste Weg zu besseren xdrop-Ergebnissen ist, alle operativen Eingaben direkt mitzugeben:

• exakte Dateipfade
• exakte Server- oder Share-URL
• gewünschte Ablaufzeit
• gewünschtes Ausgabeverzeichnis
• ob Sie JSON möchten
• ob stdout ruhig bleiben muss

Das nimmt den größten Teil des Rätselratens heraus und vermeidet Korrekturschleifen.

Das Share-URL-Fragment unbedingt erhalten

Ein häufiger Fehler bei der xdrop-Nutzung ist, dass beim Kopieren zwischen Tools das #k=...-Fragment verloren geht. Fehlt dieses Fragment, kann die lokale Entschlüsselung scheitern, selbst wenn die Transfer-ID gültig ist. Weisen Sie Nutzer ausdrücklich darauf hin, die vollständige URL unverändert zu übergeben.

Für nachgelagerte Automatisierung JSON bevorzugen

Wenn ein anderes Tool, Skript oder ein Agent das Ergebnis weiterverarbeiten soll, bevorzugen Sie:

• Upload mit --json
• Download mit --json

Das erhöht die Zuverlässigkeit, weil Sie keine menschenorientierten Konsolentexte parsen müssen.

Vor dem Skalieren zuerst mit einem kleinen Transfer testen

Für bessere Ergebnisse mit xdrop in der Datei-Automatisierung sollten Sie den vollständigen Roundtrip zuerst mit einer kleinen Datei validieren:

1. eine kleine Testdatei hochladen
2. die zurückgegebene Share-URL erfassen
3. sie in ein temporäres Verzeichnis herunterladen
4. prüfen, ob der Dateiinhalt den Erwartungen entspricht

So lassen sich Umgebungs- und Serverprobleme isolieren, bevor Sie Zeit in die Fehlersuche bei großen Transfers investieren.

Output- und Quiet-Flags bewusst einsetzen

Zwei kleine Entscheidungen verbessern die Qualität deutlich:

• verwenden Sie --output, wenn der Download-Pfad für spätere Schritte wichtig ist
• verwenden Sie --quiet, wenn Logs die maschinelle Auswertung stören würden

Diese Flags wirken auf dem Papier unscheinbar, haben in realen Pipelines aber großen Einfluss.

Concurrency nur bei Bedarf anpassen

Das Upload-Skript unterstützt --concurrency, aber mehr ist nicht automatisch besser. Erhöhen Sie den Wert nur, wenn Sie sicher sind, dass Server und Netzwerkpfad zusätzliche Parallelität verkraften. Andernfalls bleiben Sie beim Standardverhalten und optimieren auf verlässlichen Abschluss.

Serverspezifische API-Unterschiede früh abfangen

Wenn Ihre Xdrop-Deployment die API nicht unter dem Standardpfad <server>/api/v1 bereitstellt, setzen Sie --api-url sofort, statt später rätselhafte Fehler zu debuggen. Das gehört zu den ersten Punkten, die Sie prüfen sollten, wenn xdrop eigentlich korrekt aussieht, aber nicht mit dem Server sprechen kann.

Prompts im ersten Anlauf mit ausführbaren Details verbessern

Ein starker xdrop-Leitfaden für Prompts sieht so aus:

Use the xdrop skill. Upload `./release.zip` to `https://xdrop.example.com`.
Set `--expires-in 1800`, return `--json`, and suppress progress with `--quiet`.
If the upload succeeds, report only `shareUrl` and `expiresAt`.

Warum das funktioniert:

• das Skill wird direkt benannt
• der konkrete Quellpfad ist enthalten
• Server, Ablaufzeit und Ausgabeformat sind spezifiziert
• die erwartete Form der Antwort ist klar definiert

Die wahrscheinlichsten Fehlerquellen zuerst prüfen

Wenn xdrop fehlschlägt, prüfen Sie diese Punkte in dieser Reihenfolge:

1. Bun ist installiert und ausführbar
2. lokale Pfade existieren tatsächlich
3. die Server-URL ist erreichbar
4. die vollständige Share-URL enthält #k=...
5. der API-Root braucht --api-url
6. Transfergröße oder Umgebungsgrenzen werden überschritten

Diese Reihenfolge löst Probleme meist schneller, als das ganze Repository zu lesen.

Was Sie nach einem schwachen ersten Ergebnis ändern sollten

Wenn der erste xdrop-Durchlauf unübersichtlich oder unvollständig war:

• fügen Sie --json hinzu, wenn das Parsen der Ausgabe fragil war
• fügen Sie --quiet hinzu, wenn Logs stdout verschmutzt haben
• fügen Sie --output hinzu, wenn Dateien am falschen Ort gelandet sind
• ersetzen Sie vage Dateiverweise durch exakte Pfade
• testen Sie gegen einen lokalen oder nachweislich funktionierenden Xdrop-Server, bevor Sie dem Skript die Schuld geben

Diese Änderungen verbessern den zweiten Durchlauf meist stärker, als den gesamten Workflow neu zu schreiben.