Installation LaunchDarkly SDK (onboarding)
Installe et initialise le bon SDK LaunchDarkly pour le projet de l'utilisateur en suivant trois nested skills dans l'ordre. Ne pas sauter directement aux feature flags ici—la skill parent Onboarding LaunchDarkly continue avec Step 6: First feature flag en utilisant Create first feature flag.
Prérequis
- Contexte du projet de la skill parent Step 1: Explore the Project (le réutiliser ; relancer la deep detection uniquement si quelque chose n'est pas clair)
- SDK key / client-side ID / mobile key : Nécessaires quand vous atteignez Apply code changes (env wiring). Ne pas demander à l'utilisateur ces données pendant detect ou plan simplement parce que vous avez ouvert cette skill—suivre l'onboarding parent : le statut du compte est déduit via MCP OAuth (Step 4) ou surfacé en D7 dans apply ; le matériel clé est collecté dans apply (voir parent Prérequis).
Types de clés (résumé)
| Type SDK | Variable (logique) | Source dans LaunchDarkly |
|---|---|---|
| Server-side | LAUNCHDARKLY_SDK_KEY |
Environments → SDK key |
| Client-side | Client-side ID (env names avec préfixe bundler) | Environments → Client-side ID |
| Mobile | LAUNCHDARKLY_MOBILE_KEY |
Environments → Mobile key |
Ne jamais coder en dur les clés. Règles env complètes, consentement et tables bundler : Apply code changes Step 2.
Workflow — exécuter ces nested skills dans l'ordre
Exécuter les trois sauf si l'arbre de décision detect court-circuite (ex. passer directement à apply uniquement). Chaque nested skill peut contenir des points de décision — certains bloquants (marqués D<N> -- BLOCKING, où vous devez appeler votre structured question tool et attendre la réponse de l'utilisateur avant de continuer) et certains non-bloquants (où vous présentez l'information et continuez sauf si l'utilisateur s'y oppose). Ne PAS traiter par lot les appels aux outils aux limites bloquantes.
| Ordre | Nested skill | Rôle |
|---|---|---|
| 1 | Detect repository stack | Langage, package manager, cible monorepo, entrypoint, utilisation LD existante |
| 2 | Generate integration plan | Choix SDK, fichiers à modifier, plan env -- présenté à l'utilisateur (non-bloquant ; voir plan SKILL.md D6) |
| 3 | Apply code changes | Installer package(s), .env / secrets avec consentement, code init, vérification de compilation (les deux tracks quand dual-SDK plan) |
Références partagées pour toutes les étapes : SDK recipes, SDK snippets.
Après que Step 3 soit complétée
Continuer avec la skill parent :
- Step 6 : Create first feature flag
Ne pas ajouter d'évaluation « sample flag » autonome dans cette skill sauf si l'utilisateur en a explicitement besoin ; le flux parent crée le premier flag dans l'ordre.
Directives
- Correspondre aux conventions du codebase existant pour les imports, la config et le style.
- Préférer TypeScript dans les projets TypeScript.
- Si le projet utilise une couche de config partagée, initialiser LaunchDarkly là.
- Ajouter des entrées
.env.examplequand le projet utilise dotenv. - Portée de dépendance : Ajouter uniquement les package(s) SDK LaunchDarkly de la recipe sauf si l'utilisateur approuve explicitement la mise à jour ou l'ajout d'autres packages (Apply — Permission before changing other dependencies).
Cas limites
- Plusieurs environnements (ex. Next.js server + client) ou l'utilisateur a demandé frontend + backend : Utiliser un plan dual-SDK et apply les deux packages et les deux inits—ne jamais résumer le second SDK comme fait sans evidence lockfile + entrypoint.
- Monorepo : Intégrer le package que l'utilisateur a choisi dans l'onboarding parent ; rester dans ce sous-arbre.
- SDK déjà installé et initialisé : La skill parent peut sauter ce handoff—voir parent Edge Cases et arbre de décision detect.
- Stack non supporté ou peu courant : Utiliser SDK recipes et le catalog SDK complet.