$npx -y skills add launchdarkly/ai-tooling --skill planGenerate a minimal LaunchDarkly SDK integration plan from detected stack: choose SDK type(s), dual-SDK server+client when required, files to change, env conventions. Nested under sdk-install; follows detect, precedes apply.
| 1 | # Generate integration plan (SDK install) |
| 2 | |
| 3 | Based on what you detected, choose the right SDK and plan the minimal set of changes needed. |
| 4 | |
| 5 | This skill is nested under [LaunchDarkly SDK Install (onboarding)](../SKILL.md); the parent **Step 2** is **plan**. **Prior:** [Detect repository stack](../detect/SKILL.md). **Next:** [Apply code changes](../apply/SKILL.md). |
| 6 | |
| 7 | ## Choose the right SDK |
| 8 | |
| 9 | Use the [SDK recipes](../../references/sdk/recipes.md) reference to match the detected stack to an SDK. Start with **Top 10 SDKs (start here)** in that file for common stacks; use the **(other)** sections for less common SDKs. |
| 10 | |
| 11 | The key decision: |
| 12 | |
| 13 | | Project Type | SDK Type | Key Type | |
| 14 | |-------------|----------|----------| |
| 15 | | Backend API, server-rendered app, CLI tool | Server-side SDK | SDK Key | |
| 16 | | Browser SPA (React, Vue, Angular, vanilla JS) | Client-side SDK | Client-side ID | |
| 17 | | iOS or Android native app | Mobile SDK | Mobile Key | |
| 18 | | React Native | Mobile SDK | Mobile Key | |
| 19 | | Flutter (iOS, Android, or desktop **app** targets) | Client-side SDK (Flutter) | Mobile Key | |
| 20 | | Flutter **web** | Client-side SDK (Flutter) | Client-side ID | |
| 21 | | Electron desktop app | Client-side SDK (Node.js) | Client-side ID | |
| 22 | | Cloudflare Workers, Vercel Edge, AWS Lambda@Edge | Edge SDK | SDK Key | |
| 23 | | .NET client (MAUI, Xamarin, WPF, UWP) | Mobile SDK (.NET) | Mobile Key | |
| 24 | | C/C++ client application | Client-side SDK (C/C++) | Mobile Key | |
| 25 | | C/C++ server application | Server-side SDK (C/C++) | SDK Key | |
| 26 | | Haskell server | Server-side SDK (Haskell) | SDK Key | |
| 27 | | Lua server | Server-side SDK (Lua) | SDK Key | |
| 28 | | Roku (BrightScript) | Client-side SDK (Roku) | Mobile Key | |
| 29 | |
| 30 | For every supported SDK, package name, install hint, and official **Docs** link, use [SDK recipes](../../references/sdk/recipes.md) and the linked files under [`snippets/`](../../references/sdk/snippets/). |
| 31 | |
| 32 | ## Dual SDK integrations |
| 33 | |
| 34 | Use this section when the user asked for **both** a server-side and a client-side integration, or when the stack clearly needs **two** LaunchDarkly SDKs (e.g. Next.js with server evaluation **and** browser UI flags, separate backend + SPA repos in one workspace target, etc.). |
| 35 | |
| 36 | **Do not** "complete" onboarding with a single SDK while **hand-waving** the second (no second package in `package.json`, no second init path, no second recipe followed). Each SDK is a separate product with its own install command and initialization. |
| 37 | |
| 38 | For **each** of the two SDKs, the plan must spell out (with no gaps): |
| 39 | |
| 40 | **Server-side track:** |
| 41 | |
| 42 | 1. Recipe / [SDK recipes](../../references/sdk/recipes.md) row or snippet name |
| 43 | 2. Package name(s) (exact artifact) |
| 44 | 3. Install command (full command from recipe) |
| 45 | 4. Dependency file (where the line is added) |
| 46 | 5. Entrypoint file(s) (e.g. `instrumentation.ts`, API entry, `main.py`) |
| 47 | 6. Env vars (typically `LAUNCHDARKLY_SDK_KEY`) |
| 48 | 7. Init summary (where it runs; which doc/snippet) |
| 49 | |
| 50 | **Client-side track:** |
| 51 | |
| 52 | 1. Recipe / snippet name (**different** row than server) |
| 53 | 2. Package name(s) (e.g. React Web vs Node server -- must be the **client** artifact) |
| 54 | 3. Install command (**second** command -- never implied) |
| 55 | 4. Dependency file |
| 56 | 5. Entrypoint file(s) (e.g. `app/providers.tsx`, root layout, `main.tsx`) |
| 57 | 6. Env vars (bundler-prefixed **client-side ID**, e.g. `NEXT_PUBLIC_...`) |
| 58 | 7. Init summary (provider/wrapper/hook from **client** recipe) |
| 59 | |
| 60 | If you cannot name **two** packages and **two** entrypoints, you are not done planning -- go back to [SDK recipes](../../references/sdk/recipes.md) and detection. |
| 61 | |
| 62 | **Important distinctions:** |
| 63 | |
| 64 | - **Next.js**: Server-side SDK for API routes / server components / RSC contexts that evaluate on the server; React client SDK for client components. If the user requested **both**, the plan lists **both** tracks in full. If they only want one surface to start, state that explicitly in the plan. |
| 65 | - **Node.js**: If it's a backend service (Express, Fastify, etc.), use the server-side SDK. There is also a [Node.js client SDK](https://launchdarkly.com/docs/sdk/client-side/node-js) for desktop/Electron apps. |
| 66 | - **React**: If it's a standalone SPA, use `launchdarkly-react-client-sdk`. If it's part of Next.js, see above. |
| 67 | - **.NET**: Use the **server** SDK (`LaunchDarkly.ServerSdk`) for ASP.NET and backend services. For MAUI, Xamarin, WPF, and UWP, use the **.NET mobile SDK** (`LaunchDarkly.ClientSdk`, **mobile key**) -- [SDK recipes -- .NET (Client)](../../references/sdk/recipes.md#net-client). **Blazor WebAssembly** (and other browser-hosted .NET client UI) still uses `LaunchDarkly.ClientSdk` but with a **client-side ID**, not a mobile |