Guide d'expérience LaunchDarkly

Tu utilises une skill qui transforme un vague « je devrais probablement faire un A/B test » en une expérience LaunchDarkly concrète, prête à créer. Ton utilisateur est probablement un développeur qui n'a jamais conçu d'expérience : il ne sait peut-être pas ce qu'est une métrique, à quoi devrait ressembler une hypothèse, ou laquelle de ses features vaut la peine d'être testée. Ton travail consiste à réfléchir avec lui — déduire ce que son produit est à partir du code, regarder ce qui existe déjà dans son compte LaunchDarkly, proposer une expérience raisonnable ancrée dans ce contexte, brancher le code dont il a besoin, et lui remettre un brouillon qu'il peut créer en une confirmation.

Fais le gros travail. Propose, fixe des valeurs par défaut et explique. Ne le force jamais à fournir quelque chose que tu pourrais raisonnablement déduire, et ne noie jamais le jargon.

Prérequis

• Un codebase local (cette skill lit des fichiers et git log).
• Une connexion à LaunchDarkly qui peut créer des métriques et des expériences — soit un serveur LD MCP qui expose ces outils, soit un token d'API LaunchDarkly dans l'environnement (LD_API_KEY / LAUNCHDARKLY_ACCESS_TOKEN) pour les appels REST. Un MCP « flags uniquement » n'est pas suffisant : il peut scanner et faire un brouillon, mais pas créer. L'étape 0 vérifie les capacités spécifiques et s'arrête net si le chemin de création manque, proposant un plan brouillon uniquement au lieu de traîner tout le flux jusqu'à une impasse.

Cette skill orchestre plusieurs skills ciblées plutôt que de les réimplémenter. Quand une étape en appelle une, utilise-la :

Principes fondamentaux

1. Déduis, puis confirme. Propose ce que le produit est, ce à quoi tester et ce à mesurer à partir de preuves réelles dans le repo et le compte. Montre à l'utilisateur ta lecture et laisse-le la corriger avant de continuer.
2. Réutilise avant de créer. Vérifie toujours qu'un flag ou une métrique existants ne conviendraient pas avant d'en créer un nouveau. Les doublons sont la #1 façon de rendre les expériences désordonnées.
3. Une hypothèse, une métrique primaire, un changement. Garde la première expérience petite et lisible. Les métriques de garde-fou, c'est bon ; une deuxième « primaire » ne l'est pas.
4. Explique dans sa langue. Dis « la chose que tu espères améliorer » avant de dire « métrique primaire ». Définis un terme la première fois que tu l'utilises.
5. Brouillon, puis demande. Ne crée jamais rien dans LaunchDarkly sans montrer le brouillon complet et obtenir un oui explicite. Les écritures sont le choix de l'utilisateur.

Workflow

Étape 0 : Vérifier la connexion LaunchDarkly (s'arrêter tôt en cas d'erreur)

Avant tout travail, confirme que tu peux réellement atteindre LaunchDarkly. Cela décide ce que la skill peut faire et évite une impasse après que l'utilisateur a investi du temps.

Vérifie les capacités, pas juste « un MCP est connecté ». Le flux a besoin de trois choses — confirme que chacune est réellement disponible avant de la supposer, pour ne découvrir un outil manquant qu'à l'étape de création :

• Lecture de compte — lister les flags, métriques, environnements (réutilisation à l'étape 2).
• Création de métrique — créer une métrique et son événement (étape 5, si aucune ne convient).
• Création + démarrage d'expérience — créer l'expérience (étape 8) et, plus tard, démarrer son itération.

Résous un chemin, dans l'ordre de priorité :

1. Un MCP LD qui expose les outils d'expérience + métrique (create-experiment, start-experiment-iteration, create-metric, list-metrics, …) → chemin MCP complet. Préféré.
2. Sinon un token d'API LaunchDarkly (LD_API_KEY / LAUNCHDARKLY_ACCESS_TOKEN) → chemin complet via l'API REST.
3. Partiel — un MCP LD est connecté pour les flags/environnements mais n'a pas les outils d'expérience/métrique, et il n'y a pas de token d'API. Tu peux lire le compte (le scan de l'étape 2 fonctionne toujours), mais tu ne peux pas créer la métrique ou l'expérience. Scanne et fais un brouillon comme normal, puis arrête-toi avant tout écriture — voir « Agir selon le résultat » ci-dessous. Ce n'est pas « pas de connexion ».
4. Aucun accès LD du tout → tu ne peux même pas lire le compte. Arrête à l'étape 0. Ne commence pas l'étape 1 : pas de lecture de fichiers projet, pas de git log, pas de supposition sur ce qu'est le produit.

Vérifie que les outils de création spécifiques existent à l'étape 0 — « un MCP LD est connecté » ne signifie pas que tu peux créer une expérience. Un MCP « flags uniquement » te laissera scanner et faire un brouillon, puis échouera à l'étape 8 ; attraper ça maintenant, c'est tout l'intérêt de la vérification préalable.

Agir selon le résultat :

• Complet (1 ou 2) : procède à travers le workflow entier.
• Partiel (3) : tu peux atteindre le compte, donc lance toujours le scan de l'étape 2 et réutilise ce qui convient, puis produis le brouillon. À l'étape 8, arrête-toi avant tout écriture et dis à l'utilisateur que tu ne peux pas créer à partir d'ici — propose de connecter un chemin capable de créer (un MCP LD capable d'expériences ou un token LD_API_KEY) et de relancer, ou prendre le brouillon + les commandes prêtes à exécuter et finir dans l'interface ou via launchdarkly-experiment-setup. Ne dis pas à l'utilisateur que LaunchDarkly est inaccessible — ce n'est pas le cas ; tu ne peux juste pas créer à partir d'ici.
• Pas d'accès (4) : arrête maintenant. Ta réponse entière est le message ci-dessous — pas de lecture de produit, pas de résumé du code, rien des étapes suivantes — et puis attends l'utilisateur. L'utilisateur décide de se connecter avant tout travail de découverte, pas après. Seulement si l'utilisateur dit brouillon uniquement continues-tu, en commençant à l'étape 1 (pas de scan de compte, pas d'écritures — travaillant seulement à partir du codebase) :

  « Je peux lire ton code, mais je ne peux pas atteindre ton compte LaunchDarkly — donc je ne peux pas voir tes flags/métriques existants ou créer l'expérience. Connecte le serveur LaunchDarkly MCP (guide de configuration : https://launchdarkly.com/docs/home/getting-started/mcp-hosted) ou définis un token LD_API_KEY dans ton shell et redémarre cette session, puis relance. Ou dis « brouillon uniquement » et je vais produire l'hypothèse, le plan de métrique/flag, les snippets de code, et les appels d'API exacts — sans toucher à ton compte. »

Capacités par connexion :

Étape 1 : Comprendre le produit (scan léger)

Commence cette étape seulement une fois que l'étape 0 a trouvé un accès (complet ou partiel) ou que l'utilisateur a choisi brouillon uniquement.

Construis un modèle mental rapide de ce que cette appli est et qui l'utilise. Garde-le simple — tu n'audites pas le codebase entier.

Regarde :

• README*, le manifeste du package (package.json, pyproject.toml, go.mod, Gemfile, etc.) — nom, description, dépendances, frameworks.
• Les répertoires de premier niveau et les entrypoints — est-ce une app web, une API, une app mobile, une CLI ? Quelles sont les surfaces majeures (checkout, onboarding, recherche, feed) ?
• git log --oneline -n 30 et les diffs récentes — sur quoi l'équipe a-t-elle travaillé dernièrement ? Les features récentes sont des candidats d'expérience privilégiés parce que l'équipe s'en soucie déjà.

Puis résume ta lecture en une ou deux phrases et confirme, par ex. « Ça ressemble à une vitrine e-commerce React ; le travail récent a porté sur un checkout redessiné et un nouveau widget de recommandation de produits. C'est ça ? » Corrige la trajectoire selon sa réponse avant de continuer. Voir le guide de découverte pour ce à chercher par stack.

Étape 2 : Voir ce qui est déjà dans LaunchDarkly

Scanne le compte connecté pour réutiliser au lieu de dupliquer et pour que tes suggestions correspondent à leurs conventions. (Requiert la connexion de l'étape 0 — en mode brouillon uniquement, saute ce scan et dis à l'utilisateur que tu proposes sans visibilité sur ses flags et métriques existants.)

• Flags — lister les flags existants (MCP list-flags / REST GET /api/v2/flags/{projectKey}). Note les conventions de nommage, les tags, et si un flag gate déjà la feature que tu penses tester.
• Métriques — lister les métriques existantes (MCP list-metrics / REST GET /api/v2/metrics/{projectKey}). Si une métrique pertinente existe déjà (ex. checkout-completed), préfère-la comme métrique primaire de l'expérience.
• Environnements — lister les environnements du projet (MCP get-project, ou get-environment pour les détails d'un environnement) pour que tu cibles le bon et que tu connaisses la clé d'environnement.
• Projet et environnement — si le compte a plus d'un projet, demande à l'utilisateur lequel cette appli utilise au lieu de deviner. Lance l'expérience dans l'environnement auquel l'appli se connecte : fais correspondre l'ID client-side de l'appli aux environnements que get-project retourne, et demande s'il n'y a pas de correspondance ou si l'appli utilise une clé SDK serveur.

Résume ce que tu as trouvé qui soit pertinent : « Tu as déjà une métrique de conversion checkout-completed et un flag new-checkout — on peut construire l'expérience sur ceux-là au lieu de créer quelque chose de nouveau. »

Étape 3 : Choisir ce sur quoi expérimenter

Combine les étapes 1–2 en une courte liste de candidats d'expériences et laisse l'utilisateur choisir. Mène avec le candidat le plus fort (généralement une feature récente qui a, ou pourrait avoir, un flag). Présente comme un choix structuré, par exemple :

• Checkout redessiné — tester le nouveau flux vs. l'actuel. (recommandé — travail récent, directement lié aux revenus)
• Widget de recommandation — tester le montrer vs. le cacher sur les pages de produits.
• Autre chose — décris-le.

Si rien d'évident ne ressort, demande quel résultat il se soucie le plus (inscriptions, conversion, rétention, latence) et travaille à rebours vers une feature.

Étape 4 : Formuler l'hypothèse

La plupart des utilisateurs se figent ici. Ne demande pas une hypothèse à froid. Au lieu de cela :

1. Génère 1–2 candidats de la feature choisie, dans la forme standard : « Changer X va améliorer métrique pour audience, parce que raison. » par ex. « Montrer le checkout redessiné va augmenter la complétion du checkout pour les acheteurs connectés, parce que ça élimine deux étapes de formulaire. »
2. Montre un exemple travaillé à côté pour qu'il voie la forme.
3. Laisse-le choisir, modifier, ou écrire le sien.

Une bonne hypothèse nomme le changement, la métrique qu'il devrait faire bouger, la direction, et (idéalement) une taille approximative. Voir le guide d'hypothèse pour les templates, les exemples travaillés par type de produit, et comment transformer un objectif vague en une affirmation testable.

Étape 5 : Aligner la métrique

L'hypothèse nomme ce que tu espères améliorer — c'est la métrique primaire (le nombre unique qui décide l'expérience).

• Si une métrique convenable existe déjà (étape 2), utilise-la. Confirme la clé.
• Sinon, délègue à launchdarkly-metric-choose pour choisir le bon type (conversion vs. numérique, quel événement), puis à launchdarkly-metric-create pour le créer. Si l'événement n'est pas encore émis du code, launchdarkly-metric-instrument ajoute l'appel track().
• Offre 0–2 métriques de garde-fou (les choses qui ne devraient pas s'empirer, ex. taux d'erreur, latence) — mais garde exactement une primaire.

Donne à l'utilisateur le snippet de code de tracking qu'il a besoin de coller, adapté à son SDK.

Étape 6 : Aligner le flag

L'expérience a besoin d'un flag avec au moins deux variations pour diviser le trafic entre (contrôle vs. traitement).

• Si un flag gate déjà la feature, réutilise-le ; confirme qu'il a les bonnes variations et trouve sa règle de ciblage.
• Sinon, délègue à launchdarkly-flag-create pour créer un qui correspond aux patterns de flag existants du codebase, et pour encapsuler la feature dedans. Donne à l'utilisateur le snippet d'évaluation du flag pour son SDK.
• Si l'appli utilise un SDK navigateur ou mobile, crée le flag avec disponibilité côté client activée (clientSideAvailability.usingEnvironmentId, ou usingMobileKey pour mobile), sinon l'appli ne peut pas lire le flag.

Tu auras besoin de la clé du flag, des IDs de variation, et du ruleId de ciblage + le flagConfigVersion actuel pour la règle qui va piloter l'expérience (l'id de la règle fallthrough est la chaîne "fallthrough").

Étape 7 : Faire un brouillon de l'expérience et confirmer

Assemble tout en un brouillon en langage simple et le payload concret, puis demande avant de créer quoi que ce soit.

Présente le brouillon comme ceci :

Expérience : Checkout redessiné

• Hypothèse : le checkout redessiné va augmenter la complétion d'env. 3 % pour les acheteurs connectés.
• Flag : new-checkout — Contrôle (courant) 50 % vs. Nouveau checkout 50 %.
• Métrique primaire : checkout-completed (conversion).
• Garde-fou : checkout-error-rate (ne devrait pas augmenter).
• Environnement : production · Méthodologie : Fréquentiste (défaut de LaunchDarkly).
• Ce que je vais créer : 1 métrique (existe déjà → réutiliser), expérience + première itération.

Puis demande une confirmation explicite avec des options claires : Crée-le / Change quelque chose / Donne-moi juste les étapes, je le ferai moi-même. Pose-la comme une question structurée quand ton agent la supporte, pour que le oui soit sans ambiguïté.

Étape 8 : Créer (seulement après un oui)

Crée via le chemin disponible — c'est une unique étape logique avec deux implémentations. Voir Créer l'expérience pour les appels MCP exacts et les payloads REST.

• Chemin MCP (préféré) : crée toute métrique manquante, puis appelle create-experiment avec la première itération imbriquée. (Déléguer à launchdarkly-experiment-setup gère les détails de champ et le cycle de vie.)
• Fallback REST : POST /api/v2/metrics/{projectKey} pour une nouvelle métrique, puis POST /api/v2/projects/{projectKey}/environments/{envKey}/experiments avec le body d'itération.
• Mode brouillon uniquement (pas de connexion) : tu as déjà signalé cela à l'étape 0 — ne tente aucune écriture. Présente le brouillon plus les appels d'API exacts et prêts à exécuter de la référence, et pointe-le vers launchdarkly-experiment-setup pour finir une fois qu'il sera connecté.

Crée l'expérience en tant que brouillon. Démarre-la seulement après que le flag et le code de tracking soient déployés et que l'utilisateur dise oui de nouveau. Démarrer nécessite que le flag soit activé ; si l'environnement requiert une approbation pour le changer, démarre seulement après que la demande d'approbation soit approuvée.

Après création, vérifie (MCP get-experiment / REST GET …/experiments/{key}) et rapporte : ce qui a été créé, que c'est un brouillon qui ne collecte pas de données encore, le flag/métrique auquel c'est branché, et la première chose à faire (déployer le code, puis te dire de le démarrer).

Cas limites

Ce qu'il NE FAUT PAS faire

• Ne demande pas l'hypothèse, la métrique, ou le flag de l'utilisateur sans d'abord offrir une suggestion concrète, dérivée du contexte.
• Ne crée rien dans LaunchDarkly avant de montrer le brouillon et d'obtenir un oui explicite.
• Ne lance pas le flux de découverte/hypothèse/brouillon sans une connexion LaunchDarkly — vérifie à l'étape 0 et s'arrête tôt, proposant de connecter ou d'aller brouillon uniquement.
• Ne crée pas un nouveau flag ou une nouvelle métrique quand un qui convient existe déjà.
• Ne configure pas deux métriques primaires, ou ne teste pas plusieurs changements en une expérience.
• Ne noie pas l'utilisateur en terminologie — définis les termes en langage simple en chemin.
• Ne fais pas un audit du codebase profond et lent ; c'est un scan léger avec une confirmation.
• Ne devine pas le produit ou la feature cible silencieusement — énonce et confirme.

Références

• Guide de découverte : ce à lire/grep par stack pour déduire le produit et faire ressortir les features récentes.
• Guide d'hypothèse : templates, exemples travaillés par type de produit, transformer un objectif vague en une affirmation testable.
• Créer l'expérience : l'étape de création abstraite — appels MCP et payloads REST, avec les champs exacts.