Sdk Install
Onboard LaunchDarkly by running nested detect, plan, and apply skills in order to install the correct server or client SDK without skipping to first-flag setup.
Overview
sdk-install is an agent skill most often used in Build (also Validate scope, Ship launch prep) that installs the correct LaunchDarkly SDK via detect, plan, and apply nested skills in strict order.
Install
npx skills add https://github.com/launchdarkly/agent-skills --skill sdk-installWhat is this skill?
- Ordered nested workflow: Detect → Plan → Apply—do not skip ahead to feature flags inside this skill
- Parent LaunchDarkly onboarding Step 6 first flag continues via separate Create first feature flag skill
- SDK key, client-side ID, or mobile key collected only at Apply—not during Detect or Plan
- Key-type table maps SDK type to logical variables and sourcing via MCP OAuth or apply step D7
- Three nested skills executed in order: Detect, Plan, Apply
- Parent onboarding Step 6 first flag is explicitly out of scope for this skill
- Metadata version 0.2.0, Apache-2.0 license
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 are adding feature flags but do not know which LaunchDarkly SDK fits your stack or when to wire keys without breaking the broader onboarding sequence.
Who is it for?
Onboarding a real app repo to LaunchDarkly with MCP-assisted account detection and framework-accurate SDK setup before the first flag.
Skip if: Creating or targeting feature flags without SDK install, unsupported languages, or one-off copy-paste of a snippet with no detect/plan pass.
When should I use this skill?
Install and initialize the correct LaunchDarkly SDK during onboarding by running nested skills in order: detect, plan, apply; parent Step 6 first flag is separate.
What do I get? / Deliverables
Your project has the detected SDK installed and initialized through Apply, then you hand off to parent Step 6 Create first feature flag—not ad-hoc flag creation inside sdk-install.
- Detected SDK choice and integration plan documented in the onboarding flow
- Applied dependency install and initialization code with env wiring for LaunchDarkly
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
SDK wiring is canonical on Build integrations; the skill is the sixth-step bridge before parent onboarding creates the first feature flag. integrations covers third-party SDK keys, env wiring, and framework-specific init—not ship security review or grow analytics dashboards.
Where it fits
Confirm which LaunchDarkly SDK type fits your mobile vs web split before committing to a flag strategy.
Run detect and plan on your repo, then apply env wiring for the server SDK key.
Finish Apply init so production deploys can evaluate flags on launch day without missing client-side ID setup.
How it compares
Onboarding workflow skill with nested detect/plan/apply—not a standalone flag-management or experimentation analytics tool.
Common Questions / FAQ
Who is sdk-install for?
Solo builders and small teams integrating LaunchDarkly into an existing project who need the right SDK detected, planned, and applied before their first flag.
When should I use sdk-install?
During Build integrations when onboarding LaunchDarkly; also when validating stack fit before ship, or when launch prep requires client/server/mobile SDK init—always run Detect then Plan then Apply, then use the first-flag skill for Step 6.
Is sdk-install safe to install?
Review the Security Audits panel on this Prism page; Apply will touch env files and may use SDK secrets—never commit production keys and confirm OAuth/MCP access scopes.
Workflow Chain
Then invoke: first flag
SKILL.md
READMESKILL.md - Sdk Install
# LaunchDarkly SDK Install (onboarding) Installs and initializes the right LaunchDarkly SDK for the user’s project by following **three nested skills in order**. **Do not** skip ahead to feature flags here—the parent [LaunchDarkly onboarding](../SKILL.md) continues with **Step 6: First feature flag** using [Create first feature flag](../first-flag/SKILL.md). ## Prerequisites - Project context from parent **Step 1: Explore the Project** (reuse it; only re-run deep detection if something is unclear) - **SDK key / client-side ID / mobile key:** Needed when you reach [Apply code changes](apply/SKILL.md) (env wiring). **Do not** ask the user for these during detect or plan solely because you opened this skill—follow parent onboarding: account status is inferred via MCP OAuth (Step 4) or surfaced at D7 in apply; key material is collected at apply (see parent [Prerequisites](../SKILL.md#prerequisites)). ## Key types (summary) | SDK Type | Variable (logical) | Source in LaunchDarkly | |-------------|---------------------------|-------------------------------| | Server-side | `LAUNCHDARKLY_SDK_KEY` | Environments → SDK key | | Client-side | Client-side ID (bundler-prefixed env names) | Environments → Client-side ID | | Mobile | `LAUNCHDARKLY_MOBILE_KEY` | Environments → Mobile key | **Never hardcode keys.** Full env rules, consent, and bundler tables: [Apply code changes](apply/SKILL.md) Step 2. ## Workflow — run these nested skills in order Execute **all three** unless the [detect decision tree](detect/SKILL.md#decision-tree) short-circuits (e.g. skip to apply only). Each nested skill may contain decision points — some **blocking** (marked `D<N> -- BLOCKING`, where you must call your structured question tool and wait for the user's response before continuing) and some **non-blocking** (where you present information and continue unless the user objects). Do NOT batch tool calls across blocking boundaries. | Order | Nested skill | Role | |-------|----------------|------| | 1 | [Detect repository stack](detect/SKILL.md) | Language, package manager, monorepo target, entrypoint, existing LD usage | | 2 | [Generate integration plan](plan/SKILL.md) | SDK choice, files to change, env plan -- presented to user (non-blocking; see plan SKILL.md D6) | | 3 | [Apply code changes](apply/SKILL.md) | Install package(s), `.env` / secrets with consent, init code, compile check (**both** tracks when [dual-SDK plan](plan/SKILL.md#dual-sdk-integrations)) | Shared references for all steps: [SDK recipes](../references/sdk/recipes.md), [SDK snippets](../references/sdk/snippets/). ### After Step 3 completes Continue with the parent skill: - **Step 6:** [Create first feature flag](../first-flag/SKILL.md) Do not add standalone “sample flag” evaluation in this skill unless the user explicitly needs a throwaway check; the parent flow creates the first flag in order. ## Guidelines - Match existing codebase conventions for imports, config, and style. - Prefer TypeScript in TypeScript projects. - If the project uses a shared config layer, initialize LaunchDarkly there. - Add `.env.example` entries when the project uses dotenv. - **Dependency scope:** Add only LaunchDarkly SDK package(s) from the recipe unless the user **explicitly approves** upgrading or adding other packages ([Apply — Permission before changing other dependencies](apply/SKILL.md#permission-before-changing-other-dependencies)). ## Edge cases