Apply LaunchDarkly SDK onboarding: install dependency (or dual-SDK pair), configure env and secrets with consent, add init at entrypoint(s), verify compile. Nested under sdk-install; next is run.
Detected risks:
apply executes a LaunchDarkly SDK onboarding plan by installing the SDK dependency, wiring up environment configuration and secrets with the user's consent, adding initialization code at each application entrypoint, and verifying that the project still compiles. It is the third step of a larger sdk-install onboarding flow, following the plan step and preceding the run step, and is meant to carry out a plan that has already been generated rather than to devise one.
Installation uses the exact package or module name and command from the matched SDK recipe, run with the project's own package manager, and the dependency is confirmed in the lock file or manifest afterward. When the approved plan is a dual-SDK integration, both tracks must be completed for real, two packages installed and two initializations placed in different entrypoints, and the skill refuses to claim the second SDK is set up without actually doing so; if only one track was planned but both are wanted, it returns to the plan step rather than improvising. Dependency scope is tightly bounded: installing the named LaunchDarkly package or server-plus-client pair is in scope, but any change to non-LaunchDarkly packages, such as upgrades, pins, audit fixes, or engine and resolution fields, requires an explicit blocking approval before anything runs.
Secret handling is treated as a security-critical decision point. Keys, client-side IDs, and mobile keys are never hardcoded into source and are only referenced through environment variables. Before any secret is written, a mandatory blocking question presents clear choices: tell the agent where to put it, set it up themselves given the variable name, have it written to a gitignored .env file, or defer because they have no account yet, in which case placeholders are written so the code still compiles and real keys are deferred until after signup. Keys can be fetched via MCP when the user consents. Throughout, the skill stops and waits at each structured decision point rather than inferring answers from prior context.
It is Step 3 of the sdk-install flow, following the plan step and preceding the run step.
Both tracks must be completed for real, with two packages installed and two initializations placed in different entrypoints. It will not claim the second SDK is set up without doing it, and returns to the plan step if only one track was planned but both are wanted.
Keys are never hardcoded and are only referenced via environment variables. A mandatory blocking question asks how to handle the secret, offering options to place it manually, set it up themselves, write it to a gitignored .env file, or defer without an account.
Only with explicit approval. Installing the named LaunchDarkly package or server-plus-client pair is in scope, but upgrades, pins, audit fixes, or resolution changes require a blocking approval first.
It points to the signup URL, writes placeholder environment variable names so the code still compiles, continues with the init step, and defers real keys until after account creation.
Quick Setup:
.claude/skills/Repository
launchdarkly/agent-skills