Onboarding SDK LaunchDarkly

Orchestre la configuration de LaunchDarkly dans une base de code existante : au lancement, affiche une feuille de route en chat (voir Lancement : feuille de route d'intégration) ; Étape 0 crée un journal d'intégration persistant pour qu'une nouvelle session ou l'utilisateur puisse continuer ; puis explore le projet, détecte l'agent, installe les compétences de gestion des drapeaux, configure le serveur MCP LaunchDarkly en priorité, installe et initialise le SDK (sdk-install et détection/planification/application imbriquées), et crée un premier drapeau de fonctionnalité. Compétences imbriquées : mcp-configure, sdk-install, first-flag.

Prérequis

• npx : Disponible dans le PATH lors de l'utilisation de npx skills add pour installer les compétences d'accompagnement (voir Étape 3).
• Compte LaunchDarkly (différé — déduit, non demandé d'emblée) : NE demandez PAS si l'utilisateur a un compte LaunchDarkly au démarrage. Laissez plutôt le flux de travail révéler le statut du compte naturellement :
  • Étapes 0-3 (journal, exploration, détection, installation de compétences) ne nécessitent pas de compte. Exécutez-les en premier.
  • Étape 4 (MCP) : Présentez le lien d'installation MCP. Si l'utilisateur complète OAuth avec succès, il a un compte — confirmé, aucune question nécessaire.
  • Étape 5 (Clés SDK) : Si MCP n'est pas configuré (ou l'utilisateur l'a refusé), le statut du compte devient pertinent à D7 quand l'utilisateur doit fournir les clés. S'il ne peut pas fournir de clés, proposez le lien d'inscription : https://app.launchdarkly.com/signup?source=agent.
  • Cela élimine la question initiale « Avez-vous un compte ? » et laisse le flux de travail lui-même déterminer si l'utilisateur doit s'inscrire.
• Clés et jetons (différés jusqu'à nécessité) : Collectez-les uniquement quand le chemin l'exige.
  • Étape 4 — MCP : MCP hébergé utilise OAuth ; aucun token d'accès API ou clé SDK nécessaire pour le configurer. MCP local npx (fédéral/UE, etc.) : token d'accès API par mcp-configure et Modèles de config MCP.
  • Étape 5 — SDK : Clés SDK / ID côté client / clé mobile lors du câblage de l'env dans Appliquer les modifications de code, après confirmation du plan d'intégration. ldcli / REST pour la découverte : utilisez ldcli login ou un token d'accès quand vous exécutez ces commandes pour la première fois, pas au démarrage.
  • Le type de clé doit correspondre à l'intégration : SDK côté serveur -> clé SDK ; SDK côté navigateur/client -> ID côté client ; mobile -> clé mobile. Noms de variables d'env et règles de bundler : Appliquer les modifications de code.

MCP (préféré) : Complétez Étape 4 via mcp-configure/SKILL.md avant le travail SDK quand possible. Si MCP est indisponible ou l'utilisateur l'a refusé, utilisez les fallbacks ldcli / REST décrits dans cette compétence (incluant Modèles de config MCP pour le fallback local npx quand MCP hébergé ne s'applique pas) — l'intégration doit rester complétable.

Outils MCP optionnels (quand configurés) :

• get-environments — liste les environnements pour un projet ; la réponse inclut les clés SDK, les ID côté client, et les clés mobiles par environnement. Utilisez ceci comme source unique pour tous les types de clés — ne faites pas de requêtes séparées pour des clés individuelles.
• create-feature-flag — crée le drapeau booléen pour Étape 6 : Créer votre premier drapeau de fonctionnalité.
• update-feature-flag — basculer ou corriger la configuration du drapeau durant Étape 6 ; voir Créer le premier drapeau de fonctionnalité pour les fallbacks ldcli/API.

Autres outils MCP que vous pouvez utiliser si présents (non obligatoires) : list-feature-flags, get-feature-flag, get-flag-status-across-environments.

Directives de comportement de l'agent

Suivi de la progression

La feuille de route (Étapes 0-6 + suivi) DOIT être suivie en utilisant l'outil natif de suivi des tâches de votre agent en plus du fichier journal d'intégration.

• Cursor : Utilisez TodoWrite pour créer une tâche pour chaque étape avant de commencer le travail. Mettez à jour le statut à mesure que chaque étape se complète.
• Claude Code : Utilisez TaskCreate pour créer une tâche pour chaque étape (ou TodoWrite si les tâches natives sont indisponibles).
• Autres agents : Si votre agent fournit une liste de tâches native ou un outil de suivi de progression, utilisez-le. Sinon, présentez une liste numérotée en chat et mettez-la à jour après chaque étape.

Ne travaillez PAS à travers les étapes mentalement ni ne vous fiez uniquement au journal LAUNCHDARKLY_ONBOARDING.md pour le suivi en session.

Points de décision

Quand une étape nécessite une entrée utilisateur pour déterminer une ramification, vous DEVEZ collecter la réponse en appelant un outil — n'écrivez PAS la question en texte prose dans votre réponse.

Appelez l'outil directement. Utilisez le premier outil de cette liste que votre environnement fournit :

1. AskQuestion — appelez-le avec un prompt et un tableau options
2. TaskAsk ou outil d'entrée structurée équivalent
3. (fallback) Si l'appel d'outil échoue ou aucun tel outil n'existe, ALORS rendez la question sous forme d'options numérotées en texte et attendez.

Ne décidez PAS à l'avance si vous avez l'outil. Tentez l'appel. L'appel d'outil EST la question — n'écrivez pas aussi la question en texte.

Tout au long de cette compétence et ses compétences imbriquées vous verrez des marqueurs de point de décision formatés comme ceci :

**D1 -- BLOQUANT :** <instruction pour appeler votre outil de question>
- question : "<la question>"
- options :
  - "<option A>" -> <ce qui se passe>
  - "<option B>" -> <ce qui se passe>
- ARRÊT. Ne continuez pas jusqu'à ce que l'utilisateur sélectionne une option.

Ce sont des instructions à suivre, pas du contenu à afficher. Quand vous en atteignez une : faites l'appel d'outil (ou rendez les options numérotées si aucun outil n'existe), puis ARRÊTEZ et attendez. Ne copiez PAS le texte du marqueur dans votre réponse.

Communication vers l'utilisateur

Chaque réponse durant l'intégration doit ressembler à un collègue amical et compétent guidant quelqu'un à travers la configuration — pas un moteur de flux de travail citant des instructions internes. Suivez ces règles dans toute la sortie destinée à l'utilisateur :

Structure de réponse requise. Chaque réponse substantielle d'intégration doit inclure :

1. Ce que nous venons de faire — une ou deux phrases résumant l'action complétée et son résultat.
2. Ce que nous faisons ensuite — un aperçu en langage ordinaire de l'étape suivante.
3. Ce que vous devez faire (uniquement quand l'utilisateur a une action manuelle) — une instruction concrète, pas un label vague comme « À vous ». Incluez où effectuer l'action (p. ex. « dans le terminal intégré de Cursor », « dans le dossier du projet », « dans votre navigateur », « dans Terminal macOS »).

Interdits dans la sortie destinée à l'utilisateur :

• Les ID de points de décision internes (D1, D5, D7, etc.), les numéros d'étapes comme labels (p. ex. « Étape 5 — détecter »), ou les noms de fichiers de compétence (p. ex. « sdk-install/apply/SKILL.md »).
• Citation ou paraphrase d'instructions brutes de compétence, d'en-têtes de directive, ou de markdown de ces fichiers.
• Langage de moteur de flux de travail (« BLOQUANT », « ARRÊT », « appeler votre outil de question structuré », « procéder à la compétence imbriquée suivante »).

Quand vous dites à l'utilisateur d'exécuter une commande, dites toujours où l'exécuter. Bons exemples :

• « Exécutez ceci dans le terminal intégré de votre éditeur »
• « Exécutez ceci depuis la racine du projet dans votre terminal »
• « Ouvrez un terminal dans le dossier packages/api et exécutez … »

Mauvais : « Exécutez npm install » (sans contexte de localisation).

Ton : Amical, conversationnel, et confiant — comme un collègue compétent, pas un manuel. Utilisez la première personne naturellement (p. ex. « Je viens de détecter que le drapeau a été créé, maintenant je vais… »). Supposez que le lecteur est un ingénieur donc ne sur-expliquez pas les concepts basiques (ce qu'est un gestionnaire de paquets, à quoi servent les variables d'environnement), mais expliquez brièvement les concepts spécifiques à LaunchDarkly à la première mention (ce qu'est un contexte, à quoi sert une clé SDK, pourquoi il y a différents types de clés).

Règles d'exécution des étapes

Ne traitez PAS la demande initiale de l'utilisateur (p. ex. « intégrez-moi », « configurez LaunchDarkly ») comme une permission générale pour les écritures de fichiers, les installations, ou les changements de configuration. Chaque action qui modifie le repo, installe des paquets, ou écrit des secrets nécessite son propre consentement à l'étape où elle se produit.

Points de décision bloquants (vous DEVEZ vous arrêter et attendre la réponse de l'utilisateur avant de continuer) :

Non-bloquants (vous pouvez continuer automatiquement) : Étapes 0-3 (journal, exploration, détection d'agent, installation de compétences — aucune entrée utilisateur nécessaire), aperçu du plan D6 (présentez et continuez sauf si l'utilisateur s'oppose), détection Étape 5 (lectures de fichiers uniquement), vérification de compilation (Étape 5 appliquer Étape 4), écritures de fichiers de suivi (LAUNCHDARKLY.md, règles d'éditeur).

Principes fondamentaux

1. Détectez, ne devinez pas : Inspectez le repo pour la langue, le framework, et le gestionnaire de paquets.

2. Changements minimaux : Ajoutez le code SDK aux côtés du code existant ; ne restructurez pas le projet.

3. Respectez les patterns existants : Suivez les variables d'env, fichiers config, et patterns d'initialisation déjà en usage.

4. Validez bout en bout : Confirmez que le SDK est connecté avant de traiter le premier drapeau comme preuve de succès.

5. Piste papier : Gardez le journal d'intégration Étape 0 à jour pour qu'un autre agent ou session puisse continuer sans re-dériver le contexte.

6. Orientez d'abord l'utilisateur : Pour une nouvelle demande d'intégration, montrez la feuille de route Lancement avant le travail substantiel pour que l'utilisateur comprenne l'arc complet.

7. Différez les questions de credentials : Ne posez pas de questions sur le statut du compte ou les clés d'emblée. Le statut du compte est déduit via OAuth MCP (Étape 4) ou révélé à D7 (Étape 5) quand les clés sont nécessaires. Demandez les clés SDK / tokens uniquement aux Étapes 4-5 quand la compétence de cette étape dit qu'elles sont obligatoires (Prérequis).

8. Deep-link vers le tableau de bord : Quand vous générez des URL du tableau de bord LaunchDarkly et que la clé de projet et/ou clé d'environnement sont connues (à partir d'outils MCP, d'entrée utilisateur, ou du journal d'intégration), construisez l'URL la plus spécifique possible au lieu de lier à une page générique. Utilisez ces patterns :

   Ce que vous devez montrer	Pattern URL
   Liste des drapeaux du projet	https://app.launchdarkly.com/projects/{projectKey}/flags
   Drapeau spécifique	https://app.launchdarkly.com/projects/{projectKey}/flags/{flagKey}
   Clés d'environnement / clés SDK	https://app.launchdarkly.com/projects/{projectKey}/settings/environments/{envKey}/keys
   Liste des environnements du projet	https://app.launchdarkly.com/projects/{projectKey}/settings/environments
   Tous les projets	https://app.launchdarkly.com/projects

   Générez des deep links uniquement quand les clés requises sont connues à partir des réponses d'outils ou de l'entrée utilisateur confirmée. Si elles sont inconnues, utilisez le chemin générique le plus spécifique disponible et dites à l'utilisateur comment naviguer depuis là (p. ex. « Ouvrez votre projet dans le tableau de bord LaunchDarkly, puis allez à Paramètres > Environnements pour trouver votre clé SDK »).

Lancement : feuille de route d'intégration

Quand l'utilisateur appelle ce flux d'intégration (par exemple en vous demandant de suivre cette compétence, d'exécuter l'intégration LaunchDarkly, ou de configurer les drapeaux de fonctionnalité dans le projet), traitez-le comme un lancement frais sauf si vous reprenez clairement (voir Reprise ci-dessous).

Séquence de lancement (nouvelle exécution — avant toute étape numérotée)

Effectuez celles-ci dans l'ordre dans le même tour d'assistant, puis procédez directement aux Étapes 0-3 :

1. Liste de tâches : Appelez votre outil de tâches natif (Suivi de la progression) et créez une tâche par étape pour les Étapes 0 à 6 (sept tâches minimum — une pour chacune des Étapes 0, 1, 2, 3, 4, 5, et 6, même si les Étapes 0-3 sont groupées en une seule ligne ci-dessous). Faites cela avant de rendre la feuille de route pour que le suivi de la progression soit en place.
2. Feuille de route : Donnez à l'utilisateur un bref aperçu amical de ce que vous êtes sur le point de faire. Gardez-le conversationnel — un court paragraphe ou une liste compacte va bien. Ne rendez pas une grande table par défaut (le tableau ci-dessous est votre référence interne). L'utilisateur doit comprendre l'arc (explorer le projet, configurer les outils, installer le SDK, créer un premier drapeau) sans voir les numéros d'étapes ou les labels internes.
3. Commencez les Étapes 0-3 immédiatement. Ces étapes ne nécessitent pas de compte LaunchDarkly ou aucune action utilisateur. Exécutez-les en arrière-plan et ne surfacez que les résultats : ce que vous avez trouvé (langue, framework, agent) et ce que vous avez installé (compétences d'accompagnement). Ne narrez pas chaque étape comme un heading séparé — résumez-les ensemble quand vous présentez les découvertes à l'utilisateur. Le statut du compte est déduit plus tard (voir Prérequis).

• Reprise : Si LAUNCHDARKLY_ONBOARDING.md existe déjà, lisez-le d'abord par Étapes 0-3. Montrez un résumé plus court « où nous en sommes ». Actualisez la liste de tâches pour qu'elle corresponde au journal ; continuez depuis le Étape suivante du journal.

Après présentation de l'aperçu de la feuille de route, procédez directement aux Étapes 0-3 (elles ne nécessitent aucune entrée utilisateur ou compte). Puis continuez avec Étape 4.

Flux de travail

Suivez Étapes 0-6 dans l'ordre sauf si un Cas limites dit autrement. Quand Étape 6 (premier drapeau) se termine avec succès, continuez avec Suivi par défaut.

Étapes 0-3 : Configuration (exécuter silencieusement — ne narrez pas chaque étape)

Ces quatre étapes s'exécutent automatiquement sans entrée utilisateur. Exécutez-les toutes, puis présentez un seul résumé de ce que vous avez trouvé et ce que vous avez configuré. N'AFFICHAGE PAS les headings d'étapes individuels, les messages de création de journal, ou la sortie d'installation à l'utilisateur.

Étape 0 : Journal d'intégration. Créez ou actualisez LAUNCHDARKLY_ONBOARDING.md silencieusement.

1. Cherchez un journal existant à la racine du repo : LAUNCHDARKLY_ONBOARDING.md. Si le projet garde les docs sous docs/, préférez docs/LAUNCHDARKLY_ONBOARDING.md quand ce dossier existe déjà et le fichier racine est absent.
2. Créez ou mettez à jour le fichier journal directement sans demander la permission.
3. Si vous reprenez : lisez le journal d'abord, alignez-vous avec l'étape suivante déclarée, et ne refaites le travail que le journal marque comme incomplet ou invalide.
4. Quoi écrire (mettez à jour après chaque étape numérotée complétée ou quand quelque chose d'important change) :
   • Checklist : Étapes 0-6 avec statut (pas commencé / en cours / terminé / ignoré + brève raison).
   • Contexte : ID d'agent de codage (une fois connu), résumé langue/framework, chemin cible monorepo si applicable, clé de projet LaunchDarkly et clé d'environnement quand connues (ne collez jamais les secrets ou clés SDK complètes — dites « stocké dans env » ou « fourni par l'utilisateur hors ligne »).
   • MCP : configuré oui/non, hébergé vs fallback, lien vers le chemin de config si pertinent.
   • Commandes exécutées : p. ex. npx skills add ... (pas de secrets).
   • Blocages / erreurs : ce qui a échoué et ce qui a été essayé.
   • Étape suivante : single explicit step number and name (p. ex. « Étape 5 : Installer et initialiser le SDK »).
5. Après erreurs : ajoutez ou éditez le journal avec ce qui s'est cassé et où vous reprenez.

Ce fichier est un journal de travail durant l'intégration. Après succès, il est supprimé et remplacé par LAUNCHDARKLY.md (Résumé d'intégration).

Étape 1 : Explorez le projet. Comprenez ce que vous intégrez.

1. Identifiez la langue et le framework. Vérifiez les fichiers de dépendances : package.json, go.mod, requirements.txt / pyproject.toml / Pipfile, pom.xml / build.gradle, Gemfile, *.csproj / *.sln, Cargo.toml, etc.
2. Vérifiez l'utilisation existante de LaunchDarkly. Cherchez launchdarkly, ldclient, ld-client, LDClient, @launchdarkly.
   • Si déjà présent : notez la version du SDK et les patterns ; vous pouvez raccourcir ou ignorer Étape 5 par cas limites.
   • Si absent : planifiez la configuration complète du SDK.
3. Identifiez le type d'environnement : app côté serveur, SPA client, mobile, edge, etc. — cela détermine le choix du SDK.

Détails de détection profonde : Détecter la pile du repository (imbriqué sous sdk-install).

Étape 2 : Détectez l'environnement de l'agent. Déduisez silencieusement — ne posez pas de questions à l'utilisateur.

1. Cherchez les indicateurs (dans l'ordre de priorité — arrêtez à la première correspondance forte) :
   • Cursor : .cursor/, .cursorrules, ou variables d'env CURSOR_
   • Claude Code : ~/.claude/, CLAUDE.md, ou variables d'env CLAUDE_
   • Windsurf : .windsurfrules
   • GitHub Copilot : .github/copilot/
   • Codex : ~/.codex/, AGENTS.md
2. Si plusieurs indicateurs sont présents, choisissez celui dont le runtime vous exécutez actuellement à l'intérieur. Si aucun ne correspond, défaut vers l'agent dont la surface d'outils vous observez à l'exécution.
3. Souvenez-vous de l'ID d'agent pour Étape 3 (p. ex. cursor, claude-code).

Étape 3 : Installez les compétences d'accompagnement. Installez les compétences de gestion des drapeaux depuis le repo public pour que les étapes ultérieures puissent déléguer au besoin.

npx skills add launchdarkly/ai-tooling --skill launchdarkly-flag-create launchdarkly-flag-discovery launchdarkly-flag-targeting launchdarkly-flag-cleanup -y --agent <detected-agent>

Remplacez <detected-agent> par la valeur de Étape 2. Confirmez le succès ; ignorez les compétences déjà installées.

Bundled vs public : L'orchestration et la configuration pour ce flux vivent dans ce dossier — parent SKILL.md, imbriqué mcp-configure, sdk-install (détection / planification / application), first-flag, et references/ (recettes SDK, snippets, résumé, règles d'éditeur, etc.). La commande ci-dessus installe les compétences de gestion des drapeaux du repo public launchdarkly/ai-tooling uniquement.

Après completion des Étapes 0-3 : Présentez un seul résumé à l'utilisateur couvrant ce que vous avez trouvé (langue, framework, type d'environnement, si LD est déjà intégré, agent détecté). Puis procédez à Étape 4.

Étape 4 : Configurer le serveur MCP

Remettez à mcp-configure/SKILL.md pour la configuration (MCP hébergé, installation rapide, JSON manuel, autorisation agent).

La configuration MCP nécessite que l'utilisateur agisse en dehors de l'agent (clique sur un lien d'installation rapide, complète OAuth, active le serveur dans les paramètres d'éditeur). Après présentation des instructions, dites à l'utilisateur de redémarrer ou actualiser l'agent pour que les outils MCP deviennent disponibles. Puis continuez à Étape 5 — ne vous arrêtez pas ici avec une question de confirmation.

Auto-vérification au tour suivant : Quand la conversation reprend (après que l'utilisateur redémarre ou envoie un message), sondez MCP en appelant un outil MCP léger comme list-feature-flags avec la clé de projet connue. Si l'outil répond normalement, MCP est actif — notez-le dans le journal d'intégration et utilisez les outils MCP pour les étapes ultérieures. Si l'appel échoue ou aucun outil MCP n'est visible, basculez silencieusement vers ldcli/API pour Étapes 5-6 et notez le fallback dans le journal d'intégration. Ne posez pas de question à l'utilisateur si MCP fonctionne — découvrez-le en l'essayant.

Ne dupliquez pas les procédures MCP dans ce fichier. Ne bloquez pas Étape 5 indéfiniment sur MCP.

Étape 5 : Installer et initialiser le SDK

Si le projet a déjà LaunchDarkly installé et initialisé (voir arbre de décision de détection), passez à Étape 6 : Créer votre premier drapeau de fonctionnalité.

Sinon remettez à Installer le SDK LaunchDarkly (intégration), qui exécute les compétences imbriquées dans l'ordre : Détecter la pile du repository -> Générer le plan d'intégration -> Appliquer les modifications de code, utilisant recettes SDK et snippets SDK. Si l'utilisateur a demandé les deux côté serveur et client (p. ex. API + SPA, serveur Next.js + navigateur), suivez Intégrations SDK doubles via planification et application pour que les deux SDKs soient vraiment installés et initialisés.

Points de décision bloquants dans Étape 5 (voir compétences imbriquées) : D5 (portée SDK), D7 (consentement des secrets), D8 (changements de dépendances). NE BATCHEZ PAS les appels d'outils à travers ces limites. D6 (aperçu du plan) n'est pas bloquant — présentez le plan et continuez sauf si l'utilisateur s'oppose.

Étape 6 : Créer votre premier drapeau de fonctionnalité

Créez et évaluez un drapeau booléen ; basculez et observez bout en bout.

1. Suivez Créer le premier drapeau de fonctionnalité.
2. Si la compétence launchdarkly-flag-create (installée à Étape 3) est disponible, vous pouvez l'utiliser pour les câblages de création/évaluation uniquement tout en complétant toujours le checklist de vérification/basculement dans Créer le premier drapeau de fonctionnalité. L'intégration doit rester complétable sans cela.

Installez ou actualisez les compétences de drapeau via :

npx skills add launchdarkly/ai-tooling --skill launchdarkly-flag-create -y --agent <detected-agent>

Voir D9 dans first-flag pour l'arrêt bloquant sur les erreurs d'auth.

Suivi par défaut (étapes non-numérotées)

Faites celles-ci quand l'intégration se termine — même session si possible. Ce sont des tâches de documentation et remise, pas des répétitions d'Étapes 0-6. Ne sauter pas cette section — c'est le livrable principal que l'utilisateur garde après l'intégration.

Résumé de configuration (LAUNCHDARKLY.md) — OBLIGATOIRE

Générez le résumé du repo par Résumé d'intégration. Écrivez-le directement — c'est une partie du flux d'intégration. Le LAUNCHDARKLY.md généré doit inclure tout ce qui suit (voir template dans cette référence) :

1. Détails du SDK — quel(s) SDK est/sont installé(s), noms de paquets, types de clés, fichiers d'initialisation
2. Configuration — noms de variables d'env, comment les secrets sont gérés, conventions spécifiques au bundler
3. Où trouver les choses — liens du tableau de bord avec clé de projet réelle substituée
4. Comment fonctionnent les drapeaux de fonctionnalité — un exemple de code spécifique au langage montrant l'évaluation du drapeau dans la pile de ce projet (pas un snippet générique — utilisez le même pattern que l'agent a câblé durant Étape 5)
5. Étapes suivantes / capacités avancées — liens vers Déploiements progressifs, Règles de ciblage, Expérimentation, Configs IA, Déploiements gardés, et Observabilité
6. Intégration d'agent IA — configuration du serveur MCP pour la gestion continue du drapeau pilotée par agent

Ce n'est pas le même fichier que LAUNCHDARKLY_ONBOARDING.md. Le journal d'intégration est une checklist de travail ; LAUNCHDARKLY.md est la référence permanente pour l'équipe.

Nettoyer le journal d'intégration : Après écriture de LAUNCHDARKLY.md, supprimez LAUNCHDARKLY_ONBOARDING.md (ou docs/LAUNCHDARKLY_ONBOARDING.md si c'était la localisation utilisée). C'est une partie du flux de travail — ne demandez pas la permission. Supprimer le journal de travail évite la confusion d'avoir deux docs LaunchDarkly dans le repo.

Règles d'éditeur / compétences

• Ajoutez les règles spécifiques à l'éditeur ou les hooks de compétence par Règles d'éditeur et compétences. Écrivez-les directement — c'est une partie du flux d'intégration.

Cas limites

Ce qu'il NE FAUT PAS faire

• N'installez pas un SDK sans explorer le projet et détecter la pile (Étapes 1 et 5) ; gardez le journal Étape 0 à jour au fur et à mesure.
• N'améliorez pas, ne pinoulez pas, n'ajoutez pas les dépendances non-LaunchDarkly (peer-deps, churn de lockfile, bumps « latest ») pour installer ou compiler le SDK sans approbation utilisateur explicite — voir Apply — Permission before changing other dependencies.
• Ne codez pas en dur les clés SDK dans le code source — utilisez toujours les variables d'environnement (voir Appliquer les modifications de code).
• Ne restructurez pas le projet de l'utilisateur ni ne refactorisez le code sans rapport.
• Ne créez pas de drapeaux avant que l'Étape 5 (installation SDK) ne se termine.
• N'écrivez pas les questions de points de décision en texte de chat — utilisez votre outil de question structuré (voir Points de décision).

Références

Continuité

• Étape 0 — LAUNCHDARKLY_ONBOARDING.md (journal de travail ; voir Étapes 0-3)

Étape 4 — MCP (compétence imbriquée est primaire)

• mcp-configure/SKILL.md — MCP hébergé, vérifier, cas limites (suivez ceci en premier)
• Liens UI MCP — liens HTTPS + command: pour ouvrir les paramètres MCP par éditeur
• Modèles de config MCP — par agent JSON ; Serveur local via npx quand MCP hébergé est indisponible

Étape 5 — Installation SDK (compétences imbriquées)

• sdk-install/SKILL.md — orchestre détection -> planification -> application (suivez ceci en premier)
• Détecter la pile du repository
• Générer le plan d'intégration
• Appliquer les modifications de code

Premier drapeau (Étape 6)

• Créer le premier drapeau de fonctionnalité

Suivi par défaut

• Résumé d'intégration — template pour LAUNCHDARKLY.md
• Règles d'éditeur et compétences

Index SDK

• Recettes SDK
• Snippets SDK

Compétences de drapeau publiques (installer via Étape 3)

• github.com/launchdarkly/ai-tooling — launchdarkly-flag-create, launchdarkly-flag-discovery, launchdarkly-flag-targeting, launchdarkly-flag-cleanup