Resetnak/domain-availability-skill

Compétence agent : vérifier la disponibilité de noms de domaine sur plusieurs TLD via l'API gratuite domainee.dev — aucune clé API requise

Qu'est-ce que domain-availability-skill ?

Cette compétence permet à un agent IA de vérifier la disponibilité d'un nom (marque, projet, package, etc.) sur trois surfaces essentielles lors du choix d'un nom : les TLD de domaine (via l'API gratuite et sans authentification domainee.dev), le nom du package npm, et le nom d'utilisateur/organisation GitHub. Elle est conçue pour être utilisée dans des outils comme Claude Code, Cursor, ou Codex, et fournit une réponse consolidée sous forme de tableau des TLD (disponible, pris, indéterminé) avec des statuts pour npm et GitHub. La compétence gère intelligemment les limites de débit (30 requêtes/min, 500/jour), les timeouts par TLD (retournés comme 'unknown'), et les erreurs communes comme l'utilisation du mauvais hôte API. Elle évite de solliciter des API non fiables (comme les réseaux sociaux) et propose une vérification supplémentaire optionnelle des TLD non couverts par défaut.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add Resetnak/domain-availability-skill

Installed? Explore more Recherche et analyse de données skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Vérification de disponibilité de domaine

Présentation

Vérifie si un nom est disponible sur trois surfaces dont dépend généralement une décision de nommage de projet : les TLD de domaine, le nom de package npm et le nom d'utilisateur/organisation GitHub. Chaque vérification est un appel API gratuit et sans clé — exécutez-les ensemble lorsque l'utilisateur nomme quelque chose, ou seulement la vérification de domaine si c'est tout ce qui lui a été demandé.

API Domaine

GET https://domainee.dev/api/v1/tools/domain-availability-checker?name=<nom>&tlds=<tld>&tlds=<tld>...
  • name (obligatoire) — nom de domaine sans TLD, ex. mamarque.
  • tlds (optionnel, répétable) — ex. ?tlds=com&tlds=io. Omis → par défaut com, io, dev, app, co, net, org, me, ai, xyz.
  • Aucune authentification nécessaire. Utilisez toujours l'hôte domainee.dev/api/..., pas api.domainee.dev — la page de documentation mentionne cet hôte mais il retourne 401 ("Missing Bearer token") ; le point d'accès fonctionnel et compatible CORS est sur la même origine sous domainee.dev/api.

Limite de débit : 30 req/min, 500 req/jour par IP. Le quota restant est dans les en-têtes de réponse x-ratelimit-remaining-minute / x-ratelimit-remaining-day. Un 429 inclut Retry-After — présentez-le à l'utilisateur plutôt que de réessayer silencieusement.

Succès :

{"ok":true,"data":{"name":"google","results":[
  {"tld":"com","fqdn":"google.com","available":false,"registrarHint":null},
  {"tld":"io","fqdn":"google.io","available":true,"registrarHint":null}
]}}

Erreur (ex. name manquant) :

{"ok":false,"error":{"code":"missing_param","message":"Le paramètre de requête `name` est requis (ex. ?name=mamarque)"}}

Un TLD non reconnu n'est pas une erreur — il revient simplement avec un tableau results vide.

Une recherche par registre TLD peut également expirer. L'entrée de ce TLD aura alors "available":null et un registrarHint expliquant pourquoi (ex. "L'opération a été annulée en raison d'un délai d'attente dépassé"), tandis que ok reste true et les autres TLD de la même réponse ne sont pas affectés. Traitez null comme inconnu, pas comme disponible ou pris — affichez-le comme une ligne distincte "impossible de vérifier" plutôt que de deviner. Si tous les TLD de la réponse reviennent null en même temps, c'est un hoquet transitoire sur l'ensemble de la requête, pas 10 timeouts coïncidents — réessayez l'appel une fois avant de signaler un résultat tout inconnu à l'utilisateur.

API Nom de package npm

GET https://registry.npmjs.org/<nom>

Pas d'authentification, pas d'en-têtes de limite de débit à craindre en pratique. 200 = nom pris (un package réel existe), 404 = libre. Pour les noms scopés (@scope/nom), encodez la barre oblique dans l'URL : https://registry.npmjs.org/@scope%2Fnom.

API Nom d'utilisateur/organisation GitHub

GET https://api.github.com/users/<nom>

Aucune authentification requise. 200 = pris, 404 = libre. Les requêtes non authentifiées sont limitées à 60/heure par IP (en-tête x-ratelimit-remaining) — suffisant pour quelques vérifications, mais ne bouclez pas sur une grande liste de noms candidats.

Workflow

  1. Supprimez tout TLD déjà tapé par l'utilisateur pour obtenir le nom nu.
  2. Si l'utilisateur demande simplement un domaine, appelez uniquement l'API domaine. S'il nomme un projet/startup/package/outil, exécutez les trois vérifications (domaine, npm, GitHub) pour ce seul nom — cette combinaison est le véritable objectif de la compétence, pas les domaines isolément.
  3. Appelez l'API domaine. Si l'utilisateur n'a pas spécifié de TLD particuliers, omettez tlds pour obtenir l'ensemble par défaut des 10 extensions.
  4. Affichez un résumé combiné : un tableau des TLD (disponible ✅ / pris ❌ / inconnu-timeout ⚠️, d'après registrarHint), plus une ligne chacun pour npm et GitHub (✅/❌).
  5. Demandez une fois si l'utilisateur souhaite vérifier plus de TLD (suggérez-en quelques-uns non déjà couverts, ex. .ai, .so, un ccTLD) — ne reposez pas la question pour le même nom à moins que l'utilisateur ne le mentionne à nouveau.
  6. S'il nomme d'autres TLD, répétez l'appel domaine avec seulement ces tlds et affichez les nouveaux résultats.

Les handles sociaux (X, Instagram, etc.) sont délibérément exclus — aucune de ces plateformes n'expose une vérification de disponibilité gratuite et non authentifiée ; le scraping des pages de profil n'est pas fiable et va à l'encontre de la plupart de leurs conditions d'utilisation. Dites-le si on vous le demande, plutôt que de deviner à partir d'un scrape.

Exemple

curl -s "https://domainee.dev/api/v1/tools/domain-availability-checker?name=mamarque&tlds=com&tlds=io&tlds=ai"
curl -s -o /dev/null -w "%{http_code}" "https://registry.npmjs.org/mamarque"
curl -s -o /dev/null -w "%{http_code}" "https://api.github.com/users/mamarque"

Erreurs courantes

  • Utiliser api.domainee.dev — mauvais hôte, retourne 401. Utilisez domainee.dev/api/....
  • Traiter un tableau results vide comme un échec — cela signifie que le TLD n'a pas été reconnu, pas une erreur.
  • Réessayer immédiatement après un 429 — respectez Retry-After et informez l'utilisateur, ne bouclez pas.
  • Vérifier npm/GitHub pour une simple question "ce domaine est-il libre ?" — n'interrogez ces API que lorsque l'utilisateur nomme réellement quelque chose, pas pour chaque recherche de domaine.
  • Prétendre vérifier les handles sociaux — il n'existe pas d'API fiable et gratuite pour cela ; dites que c'est hors du cadre.

Skills associés