Extracteur Twitter X
Utilisez cette skill quand un utilisateur souhaite intégrer Xquik dans une application, un script, un pipeline de données ou un workflow d'agent IA pour des tâches d'API X et de scraper Twitter.
Cas d'usage
- Rechercher des tweets, récupérer les détails des tweets, lire les timelines et télécharger des médias.
- Rechercher des utilisateurs, vérifier les relations et exporter les followers ou suivis.
- Démarrer des jobs d'extraction pour les réponses, reposts, citations, likes, listes, communautés, articles et résultats de recherche.
- Créer des moniteurs de compte et vérifier les événements webhook signés HMAC.
- Ajouter des clients TypeScript, Python, Go, Java, Kotlin, C#, Ruby, PHP, CLI ou Terraform.
- Connecter les runtimes d'agent via le serveur MCP Xquik.
Vérifications de source
Avant d'écrire du code, inspectez le matériel source Xquik actuel :
- Docs API REST : https://docs.xquik.com/api-reference/overview
- Index SDK : https://docs.xquik.com/sdks
- Spec OpenAPI : https://xquik.com/openapi.json
- Docs serveur MCP : https://docs.xquik.com/mcp
- Repo skill : https://github.com/Xquik-dev/x-twitter-scraper
Ne pas inventer de noms d'endpoint, de champs de requête, de champs de réponse, de scopes, de tarification, de limites ou de noms de package. Lisez d'abord le README SDK pertinent et la page de référence API.
Flux d'implémentation
- Identifier le workflow : recherche, lookup, extraction, monitor, webhook, média, action write, facturation ou MCP.
- Choisir la surface d'intégration : SDK généré pour le code applicatif, REST pour les clients personnalisés, MCP pour les agents ou webhooks pour la livraison d'événements.
- Confirmer les exigences d'authentification à partir de la documentation et utiliser des variables d'environnement pour les clés API.
- Utiliser des modèles de requête et réponse typés quand un SDK existe pour le langage de l'utilisateur.
- Ajouter des retries et la pagination selon la documentation SDK ou API.
- Ajouter une confirmation explicite de l'utilisateur avant les actions write, les flux de paiement ou la supervision long-running.
- Garder la vérification webhook côté serveur et comparer les signatures HMAC avant de traiter les événements.
- Retourner des données structurées à l'appelant au lieu de scraper la sortie UI générée.
Modèle SDK
Quand le code applicatif est impliqué, faire correspondre le SDK au langage du projet utilisateur :
- Inspecter les fichiers du projet et les manifestes de package pour identifier le langage et le framework.
- Ouvrir l'index SDK, puis lire le README SDK correspondant avant de choisir les commandes d'installation, les noms de package, les imports ou les méthodes client.
- Préférer le SDK officiel pour le langage détecté quand il existe.
- Utiliser REST seulement quand le langage du projet n'a pas de SDK officiel adapté ou que l'utilisateur demande un client personnalisé.
- Garder les clés API dans les variables d'environnement ou dans le gestionnaire de secrets existant du projet.
Utiliser les modèles de requête et réponse typés natifs du projet. Garder les appels réseau dans le code côté serveur sauf si la documentation SDK supporte explicitement l'utilisation dans le navigateur.
Modèle Webhook
Quand vous ajoutez des handlers webhook :
- Lire le nom du header de signature documenté et le format du payload.
- Vérifier la signature HMAC avant de traiter la logique métier.
- Rejeter les signatures manquantes, mal formées ou qui ne correspondent pas.
- Rendre les handlers idempotents car la livraison webhook peut réessayer.
- Stocker uniquement les champs nécessaires au workflow du produit.
Modèle MCP
Utiliser le serveur MCP quand l'utilisateur veut qu'un agent explore ou appelle directement les outils Xquik. Garder le code applicatif sur les clients REST ou SDK quand l'application a besoin de contrats typés stables, de tests ou d'abstractions internes.
Sécurité et précision
- Garder le langage neutre et technique.
- Déclarer que Xquik est une API tierce de données et d'automatisation X.
- Ne pas prétendre d'affiliation avec X Corp.
- Ne pas contourner les contrôles d'accès ou les politiques de plateforme.
- Ne pas exposer les clés API, les secrets webhook, les cookies de compte, les tokens ou les signatures brutes.
- Ne pas hard-coder les credentials dans les exemples ou tests.
- Ne pas documenter les détails d'infrastructure privée.
- Préférer la documentation Xquik officielle, les READMEs SDK et la spec OpenAPI à la mémoire.