apply

What this skill does

# 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 LaunchDarkly package -- I'll resolve conflicts myself"
  - "Show me the exact commands first"
- STOP. Do not write the question as text. Do not upgrade an older repo "to match the newest SDK's dependencies" silently. Do not continue until the user selects an option.

If the user **declines** broader changes: keep only the LD package addition if possible, document the conflict, and proceed with placeholders or manual steps.

## Step 2: Add the SDK key to environment configuration

**Never hardcode SDK keys, client-side IDs, or mobile keys in application source files** (only reference them via environment variables).

### Permission before secrets

**D7 -- BLOCKING (MANDATORY -- DO NOT SKIP):** Call your structured question tool now. This decision point exists for security compliance -- the user must explicitly choose how secrets are handled. Skipping this and proceeding to write keys without consent is a critical failure.
- question: "The SDK needs an SDK key (or client-side ID / mobile key) for your environment. How would you like to set up the secret?"
- options:
  - "I'll tell you where to put it"
  - "I'll set up the secret myself -- just tell me what variable name to use"
  - "Write it to a `.env` file for me"
  - "I don't have an account yet -- help me sign up" -> point to the resolved signup URL (see [Source Attribution](../../SKILL.md#source-attribution); default `https://app.launchdarkly.com/signup?source=agent`), write placeholders and continue (real keys deferred until account is ready)
- STOP. Do not write the question as text. Do not fetch keys from LaunchDarkly or write real values into the repo without the user selecting an option first. Do not infer the answer from context or prior conversation -- always present this choice.

**If the user chooses option 1 ("Tell me where to put it"):**
1. Ask where they want the secret written (file path, secrets manager, etc.)
2. Ask how they want to provide the key: paste it, or have the agent fetch it via MCP/API
3. Write the key **only** to the location the user specified
4. Do not create a `.env` or modify any other file

**If the user chooses option 2 ("I'll set it up myself"):**
1. Tell them the variable name(s) they need to set (see the table below)
2. Link them to the right dashboard page. When the project key and environment key are known: **`https://app.launchdarkly.com/projects/{projectKey}/settings/environments/{envKey}/keys`**. When only the project key is known: **`https://app.launchdarkly.com/projects/{projectKey}/settings/environments`** and tell them to select the environment. When neither is known: **`https://app.launchdarkly.com/projects`** and tell them to navigate to **Settings > Environments** to find the key.
3. Wait for the user to confirm the secret is in place before proceeding to Step 3
4. Do not fetch, write, or handle the key value at all

**If the user chooses option 3 ("Write it to a `.env` file for me"):**
1. Ask how they want to provide the key: paste it, or have the agent fetch it via MCP/API
2. Follow the [Write to `.env`](#write-to-env-when-the-user-consents) section below
3. Ensure `.env` is in `.gitignore` before writing any real values

**If the user chooses option 4 ("I don't have an account yet"):**
1. Point them to the resolved signup URL (see [Source Attribution](../../SKILL.md#source-attribution); default `https://app.launchdarkly.com/signup?source=agent`)
2. Explain that SDK key setup requires an account -- they can complete setup after signing up
3. Ensure `.env` is in `.gitignore` before writing (same check as option 3 / [Write to `.env`](#write-to-env-when-the-user-consents))
4. Write placeholder variable names to `.env` (no real values) so the code compiles
5. Continue with Step 3 (init code) using the placeholder env var references. The app will fail to connect to LaunchDarkly until real keys are set, which is expected.
6. Note in the onboarding log that key setup is pending account creation

### Fetching keys via MCP

When the user asks the agent to fetch the key (via option 1 or 3 above), use the **`get-environments`** MCP tool (if configured). Call it with the project key — the response includes each environment's **SDK key**, **client-side ID**, and **mobile key**. Do **not** make separate API requests for individual keys when `get-environments` already returns them.

```
get-environments({ request: { projectKey: "PR