Plan
Turn LaunchDarkly SDK detect output into a minimal integration plan—SDK choice, env keys, and files to touch—before your agent edits the repo.
Overview
Plan is an agent skill most often used in Build (also Validate scope, Ship launch) that generates a minimal LaunchDarkly SDK integration plan from detected stack context.
Install
npx skills add https://github.com/launchdarkly/agent-skills --skill planWhat is this skill?
- Maps detected stack to LaunchDarkly SDK recipes with a server vs client vs mobile decision table
- Plans dual-SDK server+client setups when a full-stack app needs both SDK key types
- Nested Step 2 in SDK Install: follows detect, hands off to apply with minimal change set
- References Top 10 SDK recipes first, then extended (other) SDK sections for edge stacks
- Aligns env conventions (SDK key, client-side ID, mobile key) to project type
- SDK decision table covers backend API, SPA, native mobile, React Native, and Flutter targets
- Nested Step 2 in SDK Install onboarding (detect → plan → apply)
- References Top 10 SDKs plus extended (other) recipe sections
Adoption & trust: 1.2k installs on skills.sh; 16 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You know your repo stack but not which LaunchDarkly SDK, keys, or files to change without over-scoping the integration.
Who is it for?
Repos that already ran LaunchDarkly detect and need a tight feature-flag rollout plan before coding.
Skip if: Greenfield projects with no detect output, or teams that only want docs without SDK install in the repo.
When should I use this skill?
LaunchDarkly SDK install onboarding is in progress and detect context exists; you need SDK type(s) and minimal file/env plan before apply.
What do I get? / Deliverables
You get a minimal SDK choice, env conventions, and file-level change list ready for the apply skill to implement.
- Minimal integration plan: SDK type(s), key types, env conventions
- Ordered list of files to change for apply step
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Feature-flag wiring is canonical shelf in Build because the skill outputs concrete SDK and file-change plans for implementation. Plans dual server/client/mobile SDK setups and env conventions—classic third-party product integration work, not generic PM or docs.
Where it fits
Scope a pilot flag on one service before committing to full multi-SDK rollout.
Choose server vs client SDK after detect finds a Next.js app with API routes.
Confirm env key types and file list before flipping flags in a release branch.
How it compares
Use as the structured planning step between stack detect and code apply—not as a standalone feature-flag console tutorial.
Common Questions / FAQ
Who is plan for?
Solo builders and indie teams wiring LaunchDarkly into an existing codebase with an AI coding agent, especially after running the detect skill in the same skill pack.
When should I use plan?
Use it in Build integrations when detect is done; also when validating scope before a flag pilot or when prepping a safe Ship launch checklist that depends on correct SDK placement.
Is plan safe to install?
It is planning-only and does not execute installs by itself; review the Security Audits panel on this page and verify Apache-2.0 licensing before linking SDK keys in apply.
Workflow Chain
Requires first: skill launchdarkly agent skills detect
Then invoke: skill launchdarkly agent skills apply
SKILL.md
READMESKILL.md - Plan
# Generate integration plan (SDK install) Based on what you detected, choose the right SDK and plan the minimal set of changes needed. 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). ## Choose the right SDK 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. The key decision: | Project Type | SDK Type | Key Type | |-------------|----------|----------| | Backend API, server-rendered app, CLI tool | Server-side SDK | SDK Key | | Browser SPA (React, Vue, Angular, vanilla JS) | Client-side SDK | Client-side ID | | iOS or Android native app | Mobile SDK | Mobile Key | | React Native | Mobile SDK | Mobile Key | | Flutter (iOS, Android, or desktop **app** targets) | Client-side SDK (Flutter) | Mobile Key | | Flutter **web** | Client-side SDK (Flutter) | Client-side ID | | Electron desktop app | Client-side SDK (Node.js) | Client-side ID | | Cloudflare Workers, Vercel Edge, AWS Lambda@Edge | Edge SDK | SDK Key | | .NET client (MAUI, Xamarin, WPF, UWP) | Mobile SDK (.NET) | Mobile Key | | C/C++ client application | Client-side SDK (C/C++) | Mobile Key | | C/C++ server application | Server-side SDK (C/C++) | SDK Key | | Haskell server | Server-side SDK (Haskell) | SDK Key | | Lua server | Server-side SDK (Lua) | SDK Key | | Roku (BrightScript) | Client-side SDK (Roku) | Mobile Key | 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/). ## Dual SDK integrations 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.). **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. For **each** of the two SDKs, the plan must spell out (with no gaps): **Server-side track:** 1. Recipe / [SDK recipes](../../references/sdk/recipes.md) row or snippet name 2. Package name(s) (exact artifact) 3. Install command (full command from recipe) 4. Dependency file (where the line is added) 5. Entrypoint file(s) (e.g. `instrumentation.ts`, API entry, `main.py`) 6. Env vars (typically `LAUNCHDARKLY_SDK_KEY`) 7. Init summary (where it runs; which doc/snippet) **Client-side track:** 1. Recipe / snippet name (**different** row than server) 2. Package name(s) (e.g. React Web vs Node server -- must be the **client** artifact) 3. Install command (**second** command -- never implied) 4. Dependency file 5. Entrypoint file(s) (e.g. `app/providers.tsx`, root layout, `main.tsx`) 6. Env vars (bundler-prefixed **client-side ID**, e.g. `NEXT_PUBLIC_...`) 7. Init summary (provider/wrapper/hook from **client** recipe) 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. **Important distinctions:** - **Next.js**: Server-side SDK for API rout