Update to LaunchDarkly

{
  "name": "plan",
  "description": "Generate 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.",
  "included_files": [],
  "skill_md_contents": "---\nname: plan\ndescription: \"Generate 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.\"\nlicense: Apache-2.0\ncompatibility: Requires completed or equivalent detect context (see sibling detect skill)\nmetadata:\n  author: launchdarkly\n  version: \"0.2.0\"\n---\n\n# Generate integration plan (SDK install)\n\nBased on what you detected, choose the right SDK and plan the minimal set of changes needed.\n\nThis skill is nested under [LaunchDarkly SDK Install (onboarding)](../sdk-install/SKILL.md); the parent **Step 2** is **plan**. **Prior:** [Detect repository stack](../detect/SKILL.md). **Next:** [Apply code changes](../apply/SKILL.md).\n\n## Choose the right SDK\n\nUse the [SDK recipes](../onboarding/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.\n\nThe key decision:\n\n| Project Type | SDK Type | Key Type |\n|-------------|----------|----------|\n| Backend API, server-rendered app, CLI tool | Server-side SDK | SDK Key |\n| Browser SPA (React, Vue, Angular, vanilla JS) | Client-side SDK | Client-side ID |\n| iOS or Android native app | Mobile SDK | Mobile Key |\n| React Native | Mobile SDK | Mobile Key |\n| Flutter (iOS, Android, or desktop **app** targets) | Client-side SDK (Flutter) | Mobile Key |\n| Flutter **web** | Client-side SDK (Flutter) | Client-side ID |\n| Electron desktop app | Client-side SDK (Node.js) | Client-side ID |\n| Cloudflare Workers, Vercel Edge, AWS Lambda@Edge | Edge SDK | SDK Key |\n| .NET client (MAUI, Xamarin, WPF, UWP) | Mobile SDK (.NET) | Mobile Key |\n| C/C++ client application | Client-side SDK (C/C++) | Mobile Key |\n| C/C++ server application | Server-side SDK (C/C++) | SDK Key |\n| Haskell server | Server-side SDK (Haskell) | SDK Key |\n| Lua server | Server-side SDK (Lua) | SDK Key |\n| Roku (BrightScript) | Client-side SDK (Roku) | Mobile Key |\n\nFor every supported SDK, package name, install hint, and official **Docs** link, use [SDK recipes](../onboarding/references/sdk/recipes.md) and the linked files under [`snippets/`](../onboarding/references/sdk/snippets/).\n\n## Dual SDK integrations\n\nUse 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.).\n\n**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.\n\nFor **each** of the two SDKs, the plan must spell out (with no gaps):\n\n**Server-side track:**\n\n1. Recipe / [SDK recipes](../onboarding/references/sdk/recipes.md) row or snippet name\n2. Package name(s) (exact artifact)\n3. Install command (full command from recipe)\n4. Dependency file (where the line is added)\n5. Entrypoint file(s) (e.g. `instrumentation.ts`, API entry, `main.py`)\n6. Env vars (typically `LAUNCHDARKLY_SDK_KEY`)\n7. Init summary (where it runs; which doc/snippet)\n\n**Client-side track:**\n\n1. Recipe / snippet name (**different** row than server)\n2. Package name(s) (e.g. React Web vs Node server -- must be the **client** artifact)\n3. Install command (**second** command -- never implied)\n4. Dependency file\n5. Entrypoint file(s) (e.g. `app/providers.tsx`, root layout, `main.tsx`)\n6. Env vars (bundler-prefixed **client-side ID**, e.g. `NEXT_PUBLIC_...`)\n7. Init summary (provider/wrapper/hook from **client** recipe)\n\nIf you cannot name **two** packages and **two** entrypoints, you are not done planning -- go back to [SDK recipes](../onboarding/references/sdk/recipes.md) and detection.\n\n**Important distinctions:**\n\n- **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.\n- **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.\n- **React**: If it's a standalone SPA, use `launchdarkly-react-client-sdk`. If it's part of Next.js, see above.\n- **.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)](../onboarding/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 key -- see the same recipe.\n- **Flutter**: Use the Flutter client SDK (`launchdarkly_flutter_client_sdk` -- [SDK recipes -- Flutter](../onboarding/references/sdk/recipes.md#flutter)). Use a **mobile key** for typical iOS/Android/desktop **app** builds; use the **client-side ID** (and the project's pattern for public env vars) for **Flutter web**. If the user ships multiple targets, confirm which to wire first or plan separate env/config per target.\n\n## Plan the changes\n\nYour integration plan should identify exactly:\n\n### 1. Files to modify\n\nUse the information gathered during [Detect repository stack](../detect/SKILL.md) -- specifically the detected package manager, dependency file, and application entrypoint:\n\n- **Dependency file**: The file identified during detection (e.g., `package.json`, `requirements.txt`, `go.mod`) -- use the detected package manager to add the SDK\n- **Entrypoint file**: The application entrypoint identified during detection -- where SDK initialization code will go. Dual-SDK plans list **two** entrypoints (see [Dual SDK integrations](#dual-sdk-integrations)).\n- **Environment/config file**: Prefer `.env` at the integration root for real secrets (create it if it does not exist); ensure `.env` is listed in `.gitignore` there. Use `.env.example` / `.env.sample` for placeholders only. If the project does not use dotenv, follow its existing config pattern -- see [Apply code changes](../apply/SKILL.md) Step 2 for consent, writing keys, and hybrid server+client cases.\n\n### 2. Code changes\n\nFor **each SDK** in scope (one or two tracks), describe the specific changes:\n\n1. **Add SDK dependency** -- the install command from the SDK recipe (repeat for each package when dual-SDK)\n2. **Add SDK import** -- the import statement at the top of that track's entrypoint\n3. **Add SDK initialization** -- the init code for that SDK from that recipe/snippet, placed early in the right lifecycle (server vs client)\n4. **Configure credentials** -- via environment variable, never hardcoded (SDK key vs client-side ID per track)\n\n### 3. Environment variable convention\n\nCheck how the project handles configuration:\n\n- **`.env`:** If the stack uses dotenv (or you are introducing it for LaunchDarkly), plan to create `.env` at the integration root when it is missing, then add `LAUNCHDARKLY_SDK_KEY`, `LAUNCHDARKLY_CLIENT_SIDE_ID` / bundler-prefixed client ID, or `LAUNCHDARKLY_MOBILE_KEY` as appropriate (see [Apply code changes](../apply/SKILL.md) Step 2 for names, consent before real values, and hybrid server+client cases). Plan to verify `.gitignore` includes `.env` at that root (add the entry if missing, with the same user permission as other repo edits).\n- **`.env.example` / `.env.sample`:** If present, plan **placeholder** entries only (no real secrets).\n- **Config module or `process.env`:** If the project does not use `.env`, plan to follow the existing pattern for secrets.\n\n## Present the plan\n\nBefore making any changes, summarize the plan to the user.\n\n**Single SDK:**\n\n1. Install `[package name]` using `[install command]`\n2. Add SDK dependency to `[dependency file]`\n3. Add import and initialization to `[entrypoint file]`\n4. Add `[env var]` to `.env` (create if missing; real value after user consent)\n5. Ensure `.env` is in `.gitignore`\n6. Add placeholder to `.env.example` if the project uses one\n\nOnly LaunchDarkly SDK packages will be added unless the user explicitly approves other dependency changes.\n\n**Dual SDK:** Present the same numbered format **separately for each track** (e.g. \"Server-side:\" steps 1-7, then \"Client-side:\" steps 1-7), following [Dual SDK integrations](#dual-sdk-integrations). Do not omit the second track.\n\nAfter presenting the plan:\n\n**D6 -- NON-BLOCKING (proceed unless objected):** Present the plan summary to the user with a note like \"Here's what I'm going to do -- say stop or let me know if anything looks wrong.\" Then **continue into [Apply code changes](../apply/SKILL.md)** without waiting for explicit approval. If the user objects or says something looks wrong, stop and adjust the plan before continuing.\n\nThis is intentionally non-blocking to reduce ceremony. The plan is visible to the user and they can interrupt at any time. The real safety gates are D7 (secret consent) and D8 (non-LD dependency changes) in the apply step.\n\nIf the entrypoint is ambiguous or multiple SDKs could apply, those specific questions **are** blocking -- ask them as part of the plan presentation using your structured question tool and wait for an answer before proceeding.\n\n**Do not** ask for SDK keys, client-side IDs, or mobile keys as part of plan confirmation -- the parent flow collects those at [Apply code changes](../apply/SKILL.md). The **Key type** column above is for technical planning only, not a prompt for secrets.\n\n**Do not** promise or imply that you will upgrade unrelated dependencies to satisfy the latest SDK -- [Apply](../apply/SKILL.md) requires **explicit approval** before any non-LaunchDarkly package changes.\n\n---\n\n**Upon completion:** [Apply code changes](../apply/SKILL.md)\n"
}