xdrop

Vue d’ensemble de la skill xdrop

Ce que fait xdrop

La skill xdrop aide un agent à envoyer des fichiers ou répertoires locaux vers un serveur Xdrop, puis à récupérer des fichiers depuis un lien de partage Xdrop, y compris avec déchiffrement local des transferts chiffrés. Elle convient particulièrement à l’automatisation de fichiers en terminal quand vous avez besoin d’une commande reproductible, d’une URL de partage propre et, si nécessaire, d’une sortie exploitable par machine.

Qui devrait installer la skill xdrop

Installez cette skill xdrop si vous :

• transférez des fichiers via une instance Xdrop depuis des scripts ou des workflows d’agent
• recevez des liens Xdrop du type /t/<transferId>#k=... et voulez télécharger puis déchiffrer localement
• avez besoin d’options CLI stables comme --json, --quiet, --output, --expires-in ou --api-url
• cherchez un chemin d’upload/download concret plutôt que d’improviser des appels HTTP bruts

Le vrai besoin à couvrir

La plupart des utilisateurs ne cherchent pas simplement « une skill de partage de fichiers » de manière abstraite. Ils veulent automatiser de façon fiable l’un de ces deux usages :

1. transformer des fichiers locaux en lien de partage Xdrop depuis le terminal
2. partir d’un lien Xdrop existant et restaurer les fichiers en local sans avoir à deviner le protocole

C’est là que xdrop est utile : la skill encapsule le workflow dans deux scripts directement exécutables au lieu de laisser l’agent rétroconcevoir le format de partage.

Pourquoi xdrop se distingue d’un prompt générique

Un prompt générique peut décrire le fonctionnement possible de Xdrop. La skill xdrop, elle, fournit des scripts exécutables qui gèrent déjà le chemin pratique :

• upload via scripts/upload.mjs
• analyse des liens de partage et téléchargement via scripts/download.mjs
• utilisation par défaut de la racine API attendue
• prise en charge de sorties silencieuses et JSON pour des pipelines d’automatisation propres

Contraintes essentielles à connaître avant de commencer

Avant d’adopter xdrop, vérifiez ces prérequis :

• bun est nécessaire pour exécuter les scripts fournis
• l’agent doit avoir accès au système de fichiers local
• l’agent doit avoir un accès réseau au serveur Xdrop ciblé
• les uploads visent des serveurs compatibles Xdrop, pas des hébergeurs de fichiers arbitraires

Si votre environnement ne peut pas exécuter Bun ou ne peut pas joindre le serveur visé, ce guide xdrop n’est pas la bonne approche.

Comment utiliser la skill xdrop

Installer la skill xdrop dans votre configuration Skills

Si vous utilisez le système Skills, installez xdrop avec :

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

Travaillez ensuite depuis les fichiers du répertoire de la skill :

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

Installer les prérequis d’exécution pour utiliser xdrop

La skill repose sur des scripts ; le prérequis pratique principal est donc Bun. Vérifiez que Bun est disponible avant de lancer xdrop :

bun --version

Vérifiez aussi que :

• vous pouvez lire les fichiers locaux que vous voulez envoyer
• vous pouvez écrire dans le répertoire de sortie des téléchargements
• le serveur Xdrop est joignable depuis votre environnement

Commencez par lire ces fichiers

Pour évaluer rapidement la skill, lisez dans cet ordre :

1. SKILL.md pour comprendre le workflow pris en charge et les options disponibles
2. scripts/upload.mjs pour les arguments d’upload et les limites prévues
3. scripts/download.mjs pour l’analyse des liens de partage et le comportement de sortie

Cet ordre de lecture suffit généralement pour décider si xdrop pour l’automatisation de fichiers correspond à votre pipeline.

Comprendre les deux points d’entrée principaux

La skill xdrop a volontairement un périmètre réduit. Dans la pratique, vous appellerez surtout l’un de ces deux scripts :

• Upload :

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

• Download :

  bun scripts/download.mjs <share-url>
  

Ce périmètre limité est un avantage si vous recherchez une automatisation de transfert de fichiers fiable plutôt qu’un SDK plus large.

Envoyer des fichiers avec xdrop

Un upload de base ressemble à ceci :

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

Vous pouvez aussi envoyer plusieurs chemins en une fois :

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

Utilisez cette approche quand l’objectif utilisateur est « partage ces fichiers locaux et donne-moi un lien », pas lorsqu’il faut de la synchronisation de stockage, de la navigation ou des fonctions de gestion de compte.

Exploiter les options d’upload adaptées à l’automatisation

Les options les plus utiles en automatisation réelle sont :

• --json pour une sortie structurée exploitable en aval
• --quiet pour garder un stdout propre
• --expires-in <sec> pour contrôler la durée de vie du transfert
• --name <value> pour définir un libellé de transfert
• --api-url <url> si la racine API n’est pas celle attendue par défaut
• --concurrency <n> pour ajuster le parallélisme de l’upload

Exemple :

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

Dans des workflows d’agent, --json est particulièrement important, car il renvoie des champs comme transferId, shareUrl et expiresAt au lieu d’obliger à extraire ces informations depuis du texte libre fragile.

Télécharger et déchiffrer depuis un lien de partage xdrop

Le cas principal côté téléchargement est une URL Xdrop complète contenant le fragment de clé :

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

Le script analyse le lien de partage, récupère les métadonnées du transfert, télécharge le contenu chiffré et le déchiffre localement. C’est l’une des principales raisons de préférer la skill xdrop à un prompt écrit à la main : le format de lien contenant la clé est déjà pris en charge.

Maîtriser proprement l’emplacement de sortie au téléchargement

Par défaut, les téléchargements sont enregistrés dans un répertoire du type ./xdrop-<transferId>. Remplacez ce comportement si votre workflow attend un chemin précis :

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

Options utiles :

• --output <dir> pour un emplacement de fichiers déterministe
• --json pour une sortie lisible par machine
• --quiet pour des logs plus propres
• --api-url <url> lorsque la racine API diffère de <share-origin>/api/v1

Transformer une intention floue en prompt xdrop efficace

Demande faible :

upload this file to xdrop

Meilleure demande :

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.

Demande faible :

fetch this xdrop link

Meilleure demande :

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

Un bon prompt d’utilisation de xdrop inclut :

• l’URL du serveur ou l’URL complète de partage
• les chemins locaux exacts
• le répertoire de sortie souhaité
• si la sortie doit être en texte brut ou en JSON
• les besoins d’expiration côté upload

Meilleur workflow avec xdrop pour l’automatisation de fichiers

Un workflow pratique avec xdrop consiste à :

1. vérifier Bun et l’accès réseau
2. tester d’abord avec un petit fichier
3. passer à --json une fois la commande validée
4. ajouter --quiet si un autre script ou agent doit analyser stdout
5. ne passer à des transferts plus gros ou multi-fichiers qu’ensuite

Cette méthode réduit le temps de débogage, car la plupart des échecs viennent de l’environnement, des chemins erronés ou de l’accessibilité du serveur, pas de la logique de transfert elle-même.

Limites pratiques et arbitrages

D’après ce que montrent les scripts, xdrop est optimisé pour des transferts simples, pas pour des volumes massifs sans contrainte. Le script d’upload définit :

• une concurrence maximale plafonnée à 6
• une taille maximale de transfert de 256 * 1024 * 1024 octets

Autrement dit, ce guide xdrop convient mieux au partage de courte durée et aux tâches d’automatisation qu’à de très gros workflows d’archivage.

FAQ sur la skill xdrop

La skill xdrop est-elle adaptée aux débutants ?

Oui, si vous êtes à l’aise avec l’exécution de scripts Bun en terminal. L’interface reste simple, mais les débutants peuvent tout de même avoir besoin d’aide pour :

• installer Bun
• fournir les bons chemins de fichiers
• comprendre la différence entre l’URL du site et l’URL de l’API
• conserver le fragment #k=... dans un lien de partage

Dans quels cas xdrop est-il meilleur qu’un prompt classique ?

La skill xdrop est meilleure quand vous avez besoin d’exécution, pas d’explication. Un prompt classique peut décrire Xdrop, mais cette skill fournit un chemin concret d’upload/download, avec les bonnes options et un workflow de déchiffrement local déjà intégré.

Quelles informations xdrop attend-il de ma part ?

Pour l’upload :

• une URL publique de site Xdrop via --server
• un ou plusieurs chemins locaux de fichiers ou répertoires

Pour le download :

• une URL de partage complète, idéalement avec le fragment de clé
• éventuellement un répertoire de sortie et une surcharge de l’API

Sans ces entrées, l’agent devra deviner, et la qualité d’utilisation de xdrop se dégrade rapidement.

Faut-il l’URL de partage complète pour télécharger ?

Oui, en pratique, il faut fournir le lien Xdrop complet. Le script de téléchargement attend explicitement un lien de partage complet et s’en sert pour dériver l’ID de transfert, l’origine et les éléments de clé. Un simple transfer ID ne suffit pas pour un flux complet de déchiffrement local.

xdrop convient-il à la CI ou aux pipelines scriptés ?

Oui. C’est même l’une des meilleures raisons d’installer xdrop. La prise en charge de --json et --quiet le rend adapté aux scripts shell, aux jobs CI et aux chaînes d’agents où stdout doit rester analysable.

Quand ne faut-il pas utiliser xdrop ?

Évitez xdrop si :

• vous ne pouvez pas exécuter Bun
• vous avez besoin d’une expérience orientée navigateur plutôt que d’une automatisation en terminal
• vous avez besoin de fonctions au-delà de l’automatisation upload/download
• votre cible n’est pas un serveur compatible Xdrop
• votre workflow implique des fichiers au-delà des limites de transfert prévues par le script

Comment améliorer l’usage de la skill xdrop

Donner à xdrop des entrées complètes et sans ambiguïté

Le moyen le plus rapide d’améliorer les résultats avec xdrop est de fournir dès le départ toutes les informations opérationnelles :

• chemins de fichiers exacts
• URL exacte du serveur ou du lien de partage
• durée d’expiration souhaitée
• répertoire de sortie voulu
• besoin ou non de JSON
• besoin ou non de garder stdout silencieux

Vous éliminez ainsi l’essentiel des suppositions et évitez les corrections de suivi.

Préserver le fragment d’URL du lien de partage

Un mode d’échec fréquent avec xdrop consiste à perdre le fragment #k=... en copiant les liens entre outils. Si ce fragment manque, le déchiffrement local peut échouer même si le transfer ID est valide. Indiquez clairement aux utilisateurs de transmettre l’URL complète sans la modifier.

Préférer JSON pour l’automatisation en aval

Si un autre outil, script ou agent doit consommer le résultat, privilégiez :

• l’upload avec --json
• le download avec --json

La fiabilité s’en trouve améliorée, car vous évitez de parser un texte de console destiné aux humains.

Tester avec un petit transfert avant de passer à l’échelle

Pour de meilleurs résultats avec xdrop pour l’automatisation de fichiers, validez d’abord l’aller-retour complet sur un petit fichier :

1. envoyer un petit fichier de test
2. récupérer l’URL de partage renvoyée
3. le télécharger dans un répertoire temporaire
4. vérifier que le contenu correspond à ce qui est attendu

Cela permet d’isoler les problèmes d’environnement et de serveur avant de perdre du temps à déboguer de gros transferts.

Utiliser délibérément les options de sortie et de silence

Deux choix simples améliorent fortement la qualité :

• utilisez --output quand le chemin de destination compte pour les étapes suivantes
• utilisez --quiet quand les logs risquent de perturber une analyse automatisée

Sur le papier, ces options paraissent mineures ; dans de vrais pipelines, leur impact est élevé.

Ajuster la concurrence seulement si nécessaire

Le script d’upload prend en charge --concurrency, mais plus élevé ne veut pas toujours dire meilleur. Augmentez cette valeur uniquement si vous êtes certain que le serveur et le réseau peuvent absorber davantage de travail en parallèle. Sinon, gardez le comportement par défaut et privilégiez une exécution prévisible.

Gérer tôt les différences d’API propres au serveur

Si votre déploiement Xdrop expose l’API ailleurs que sur la valeur par défaut <server>/api/v1, définissez --api-url immédiatement au lieu de perdre du temps plus tard sur des échecs difficiles à expliquer. C’est l’un des premiers points à vérifier quand xdrop semble correctement configuré mais ne parvient pas à dialoguer avec le serveur.

Améliorer les prompts initiaux avec des détails directement exécutables

Un bon modèle de prompt xdrop ressemble à ceci :

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`.

Pourquoi cela fonctionne :

• la skill est nommée explicitement
• le chemin source concret est fourni
• le serveur, l’expiration et le format de sortie sont précisés
• la forme attendue de la réponse est définie

Diagnostiquer d’abord les points de panne les plus probables

Si xdrop échoue, vérifiez dans cet ordre :

1. Bun est installé et exécutable
2. les chemins locaux existent réellement
3. l’URL du serveur est joignable
4. l’URL complète de partage contient bien #k=...
5. la racine API nécessite --api-url
6. la taille de transfert ou les contraintes d’environnement sont dépassées

Dans la plupart des cas, cet ordre résout les problèmes plus vite que de lire tout le dépôt.

Que changer après un premier résultat décevant

Si le premier essai avec xdrop est brouillon ou incomplet :

• ajoutez --json si l’analyse de sortie était fragile
• ajoutez --quiet si les logs ont pollué stdout
• ajoutez --output si les fichiers ont été enregistrés au mauvais endroit
• remplacez les références vagues aux fichiers par des chemins exacts
• testez contre un serveur Xdrop local ou connu comme fiable avant d’incriminer le script

En général, ces ajustements améliorent davantage le deuxième essai que la réécriture complète du workflow.