Apply
Execute an approved LaunchDarkly integration plan: install SDK(s), configure secrets with consent, initialize at each entrypoint, and verify the project still compiles.
Overview
Apply is an agent skill for the Build phase that installs LaunchDarkly SDK(s), configures credentials with consent, adds initialization at planned entrypoints, and verifies compile—Step 3 of sdk-install.
Install
npx skills add https://github.com/launchdarkly/agent-skills --skill applyWhat is this skill?
- Step 3 of LaunchDarkly SDK Install (detect → plan → apply → run)
- Installs dependency or completes dual-SDK pair per approved plan—two packages, two inits, two credential lines when requ
- Stops and returns to plan if user asked for dual SDK but plan only covered one track
- First nested step that requests SDK key, client-side ID, or mobile key with explicit user consent
- Minimal init at each tracked surface and compile verification before run
- Parent workflow Step 3 apply
- Dual SDK requires two install commands and two inits per recipe
Adoption & trust: 1.2k installs on skills.sh; 16 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have an integration plan but need consistent installs, secret handling, and init code across one or two SDK tracks without skipping the second half of a dual setup.
Who is it for?
Builders with an approved LaunchDarkly plan ready to modify manifests, env, and entrypoint code in-repo.
Skip if: Repos that have not completed detect/plan, or teams forbidding agents from touching secrets or package installs.
When should I use this skill?
Approved LaunchDarkly integration plan exists—parent Step 3 apply—ready to install SDKs, configure credentials with consent, and verify compile.
What do I get? / Deliverables
Dependencies and minimal init land on every planned surface with credentials configured, compile checked—then invoke run to start the application.
- Installed SDK dependency or dual-SDK pair in manifest
- Env/secrets configuration with documented consent
- Init code at each planned entrypoint
Recommended Skills
Journey fit
How it compares
Follows a fixed onboarding chain (plan → apply → run) instead of one-shot “add LaunchDarkly” chat without manifest-backed steps.
Common Questions / FAQ
Who is apply for?
Solo and indie developers using the LaunchDarkly agent sdk-install workflow who already have a generated integration plan and LD credentials available.
When should I use apply?
In Build integrations as Step 3 after plan—when you are ready to install SDK packages, set env/secrets with consent, and add init code before starting the app.
Is apply safe to install?
It may install packages, edit code, and request API keys—review the Security Audits panel on this Prism page and use least-privilege agent permissions and secret handling policies.
SKILL.md
READMESKILL.md - Apply
# Apply code changes (SDK install) Execute the integration plan. Install the SDK(s) and add the minimal code needed to initialize **each** tracked surface. This skill is nested under [LaunchDarkly SDK Install (onboarding)](../SKILL.md); the parent **Step 3** is **apply**. **Prior:** [Generate integration plan](../plan/SKILL.md). **Next:** [Start the application](../run/SKILL.md). **Dual SDK:** If the approved plan is **dual SDK** ([plan: Dual SDK integrations](../plan/SKILL.md#dual-sdk-integrations)), you must complete Steps 1-3 **for both tracks** -- **two** packages in the manifest, **two** install commands run (or equivalent), **two** credential lines where needed, **two** inits in **different** entrypoints per recipe. **Do not** claim the second SDK is set up without performing its real install and init. If the plan only listed one track but the user asked for both, **stop** and return to [plan](../plan/SKILL.md) -- do not invent the second half from memory. **Credential timing:** This is the first nested step where you ask the user for **SDK key / client-side ID / mobile key** (or consent to fetch/write them). Account status is not asked upfront -- it is inferred earlier via MCP OAuth (parent Step 4) or surfaced here at D7 (option 4) if the user has no account yet ([parent Prerequisites](../../SKILL.md#prerequisites)). ## Step 1: Install the SDK dependency Use the **exact** package or module name and install command from the SDK row you already matched in [SDK recipes](../../references/sdk/recipes.md), with the project's package manager. Do not copy a generic install line from elsewhere -- each recipe names the right artifact. **Dual SDK:** Run the **install command for Track A**, then the **install command for Track B** (from the plan). Confirm **both** package names appear in `package.json` / `requirements.txt` / lockfile (or the correct package manifest for each language). Skipping the second install is **not** optional when the plan says dual. After installation, verify the dependency appears in the lock file or dependency manifest (**all** LaunchDarkly packages from the plan). ### Permission before changing other dependencies **Allowed without asking for extra permission (beyond normal repo-edit consent):** Installing **only** the LaunchDarkly SDK package(s) named in the recipe(s) for this integration (e.g. one server SDK, **or** the **exact server + client pair** listed in a dual-SDK plan -- **both** packages count as in-scope LD installs). Use the **minimum** install each recipe specifies (exact package names). **Requires explicit user approval *before* you run any command or edit manifests:** Any change beyond that scope, including but not limited to: - Upgrading, downgrading, pinning, or adding **non-LaunchDarkly** packages (peer-dependency "fixes," `npm install X@latest`, `yarn upgrade`, `pnpm update`, bumping React/Node types, transitive lockfile churn, etc.) - Running **`npm audit fix`**, **bulk updates**, or **replacing** the project's package manager resolution strategy to satisfy the SDK - Changing **engine** / **packageManager** fields, **resolutions** / **overrides**, or **workspaces** entries for reasons other than adding the LD artifact line If the package manager reports peer conflicts or install failures: **D8 -- BLOCKING:** Call your structured question tool now. - question: "The install reported [specific error]. To fix this, I would need to [specific changes to non-LD packages]. Should I proceed with those additional changes?" - options: - "Yes, make those changes" - "No, keep only the Laun