$npx -y skills add launchdarkly/ai-tooling --skill applyApply 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.
| 1 | # Apply code changes (SDK install) |
| 2 | |
| 3 | Execute the integration plan. Install the SDK(s) and add the minimal code needed to initialize **each** tracked surface. |
| 4 | |
| 5 | 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). |
| 6 | |
| 7 | **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. |
| 8 | |
| 9 | **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)). |
| 10 | |
| 11 | ## Step 1: Install the SDK dependency |
| 12 | |
| 13 | 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. |
| 14 | |
| 15 | **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. |
| 16 | |
| 17 | After installation, verify the dependency appears in the lock file or dependency manifest (**all** LaunchDarkly packages from the plan). |
| 18 | |
| 19 | ### Permission before changing other dependencies |
| 20 | |
| 21 | **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). |
| 22 | |
| 23 | **Requires explicit user approval *before* you run any command or edit manifests:** Any change beyond that scope, including but not limited to: |
| 24 | |
| 25 | - 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.) |
| 26 | - Running **`npm audit fix`**, **bulk updates**, or **replacing** the project's package manager resolution strategy to satisfy the SDK |
| 27 | - Changing **engine** / **packageManager** fields, **resolutions** / **overrides**, or **workspaces** entries for reasons other than adding the LD artifact line |
| 28 | |
| 29 | If the package manager reports peer conflicts or install failures: |
| 30 | |
| 31 | **D8 -- BLOCKING:** Call your structured question tool now. |
| 32 | - 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?" |
| 33 | - options: |
| 34 | - "Yes, make those changes" |
| 35 | - "No, keep only the LaunchDarkly package -- I'll resolve conflicts myself" |
| 36 | - "Show me the exact commands first" |
| 37 | - 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. |
| 38 | |
| 39 | If the user **declines** broader changes: keep only the LD package addition if possible, document the conflict, and proceed with placeholders or manual steps. |
| 40 | |
| 41 | ## Step 2: Add the SDK key to environment configuration |
| 42 | |
| 43 | **Never hardcode SDK keys, client-side IDs, or mobile keys in application source files** (only reference them via environment variables). |
| 44 | |
| 45 | ### Permission before secrets |
| 46 | |
| 47 | **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. |
| 48 | - question: "The SDK needs an SDK key (or client-side ID / mobile key |