Back to Details

apply

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Apply code changes (SDK install)

应用代码变更（SDK安装）

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); the parent Step 3 is apply. Prior: Generate integration plan. Next: Start the application.
Dual SDK: If the approved plan is dual SDK (plan: 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 -- 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). Earlier onboarding should have confirmed only account access, not key material (parent Prerequisites).
执行集成方案。安装SDK并添加初始化每个被跟踪所需的最少代码。
此技能属于LaunchDarkly SDK安装（入门）的子步骤；父步骤第3步为应用。前置步骤：生成集成方案。下一步：启动应用。
双SDK：如果已批准的方案为双SDK（方案：双SDK集成），你必须完成两个轨道的步骤1-3——清单中要有两个包，运行两个安装命令（或等效操作），必要时添加两行凭证，根据指南在不同入口点完成两次初始化。未实际完成第二个SDK的安装和初始化时，请勿声称已完成设置。如果方案仅列出一个轨道，但用户要求两个，请停止操作并返回方案——不要凭记忆自行补充第二部分内容。
凭证时机：这是第一个需要向用户索要SDK密钥/客户端ID/移动密钥（或获取写入权限）的子步骤。前期入门流程应仅确认了账户访问权限，而非密钥材料（父步骤前置条件）。

Step 1: Install the SDK dependency

步骤1：安装SDK依赖

Use the exact package or module name and install command from the SDK row you already matched in SDK recipes, 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).
使用你在SDK指南中匹配到的SDK行对应的精确包或模块名称，以及项目的包管理器执行安装命令。请勿从其他地方复制通用安装命令——每个指南都会指定正确的构件。
双SDK：运行轨道A的安装命令，然后运行轨道B的安装命令（来自方案）。确认两个包名称都出现在
package.json
/
requirements.txt
/锁文件（或对应语言的正确包清单）中。当方案指定为双SDK时，跳过第二个安装并非可选操作。
安装完成后，验证方案中所有LaunchDarkly包都已出现在锁文件或依赖清单中。

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.
无需额外权限（除正常仓库编辑许可外）即可执行：仅安装此集成指南中指定的LaunchDarkly SDK包（例如一个服务端SDK，或双SDK方案中列出的精确服务端+客户端组合——两个包都属于LD安装范围）。使用每个指南指定的最小化安装（精确包名称）。
**执行任何命令或编辑清单前需获得用户明确批准：**超出上述范围的任何变更，包括但不限于：
  • 升级、降级、固定或添加非LaunchDarkly包（对等依赖“修复”、
    npm install X@latest
    、
    yarn upgrade
    、
    pnpm update
    、更新React/Node类型、传递性锁文件变更等）
  • 运行**
    npm audit fix
    **、批量更新，或更换项目的包管理器解析策略以适配SDK
  • 更改engine/packageManager字段、resolutions/overrides，或workspaces条目（除非是为了添加LD构件行）
如果包管理器报告对等依赖冲突或安装失败：
**D8 -- 阻塞：**立即调用结构化提问工具。
  • 问题：“安装过程中报告了[具体错误]。要修复此问题，我需要对非LD包进行[具体变更]。是否继续执行这些额外变更？”
  • 选项：
    • “是，执行这些变更”
    • “否，仅保留LaunchDarkly包——我会自行解决冲突”
    • “先展示具体命令”
  • 停止操作。请勿将问题以文本形式写出。请勿静默升级旧仓库“以匹配最新SDK的依赖”。在用户选择选项前，请勿继续操作。
如果用户拒绝更广泛的变更：尽可能仅保留LD包的添加，记录冲突情况，并使用占位符或手动步骤继续。

Step 2: Add the SDK key to environment configuration

步骤2：将SDK密钥添加到环境配置中

Never hardcode SDK keys, client-side IDs, or mobile keys in application source files (only reference them via environment variables).
切勿在应用源码文件中硬编码SDK密钥、客户端ID或移动密钥（仅通过环境变量引用它们）。

Permission before secrets

处理密钥前需获得权限

D7 -- BLOCKING: Call your structured question tool now.
  • 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"
  • 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.
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
     section below
  3. Ensure 
    .env
    is in 
    .gitignore
    before writing any real values
**D7 -- 阻塞：**立即调用结构化提问工具。
  • 问题：“SDK需要对应环境的SDK密钥（或客户端ID/移动密钥）。你希望如何设置密钥？”
  • 选项：
    • “我会告诉你存放位置”
    • “我会自行设置密钥——只需告诉我要使用的变量名称”
    • “帮我写入
      .env
      文件”
  • 停止操作。请勿将问题以文本形式写出。在用户选择选项前，请勿从LaunchDarkly获取密钥或向仓库写入真实值。
如果用户选择选项1（“告诉我存放位置”）：
  1. 询问用户希望将密钥写入的位置（文件路径、密钥管理器等）
  2. 询问用户提供密钥的方式：粘贴，或让Agent通过MCP/API获取
  3. 仅将密钥写入用户指定的位置
  4. 请勿创建
    .env
    或修改其他任何文件
如果用户选择选项2（“我会自行设置密钥”）：
  1. 告知用户需要设置的变量名称（见下表）
  2. 提供对应仪表盘页面的链接。当项目密钥和环境密钥已知时：
    https://app.launchdarkly.com/projects/{projectKey}/settings/environments/{envKey}/keys
    。当仅知道项目密钥时：
    https://app.launchdarkly.com/projects/{projectKey}/settings/environments
    ，并告知用户选择对应环境。当两者都未知时：
    https://app.launchdarkly.com/projects
    ，并告知用户导航至Settings > Environments查找密钥。
  3. 等待用户确认密钥已设置完成后，再继续步骤3
  4. 完全不要获取、写入或处理密钥值
如果用户选择选项3（“帮我写入
.env
文件”）：
  1. 询问用户提供密钥的方式：粘贴，或让Agent通过MCP/API获取
  2. 遵循下方的写入
    .env
    文件    部分
  3. 在写入任何真实值前，确保
    .env
    已添加到
    .gitignore
    中

Fetching keys via MCP

通过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: "PROJECT_KEY" } })
Security: Treat MCP responses containing keys as sensitive. Write keys only to the location the user chose without echoing full key values in chat responses. Keys in agent conversation history or logs may persist beyond the session.
Pick the correct key type from the matching environment in the response (see table below). If MCP is not configured, fall back to 
ldcli
or the REST API (
GET /api/v2/projects/{PROJECT_KEY}/environments
).
当用户要求Agent获取密钥（上述选项1或3）时，使用**
get-environments
** MCP工具（如果已配置）。传入项目密钥调用该工具——响应结果包含每个环境的SDK密钥、客户端ID和移动密钥。当
get-environments
已返回这些信息时，请勿单独发起API请求获取单个密钥。
get-environments({ request: { projectKey: "PROJECT_KEY" } })
**安全提示：将包含密钥的MCP响应视为敏感信息。**仅将密钥写入用户选择的位置，不要在聊天响应中回显完整密钥值。Agent对话历史或日志中的密钥可能会在会话结束后继续留存。
从响应的对应环境中选择正确的密钥类型（见下表）。如果未配置MCP，退而使用
ldcli
或REST API（
GET /api/v2/projects/{PROJECT_KEY}/environments
）。

Variable names and where values come from

变量名称及值的来源

SDK TypeVariable name (typical)Source in LaunchDarkly
Server-side
LAUNCHDARKLY_SDK_KEY
get-environments
response → environment → SDK key
Client-sideLogical / bundler-prefixed name (see below)
get-environments
response → environment → Client-side ID
Mobile
LAUNCHDARKLY_MOBILE_KEY
get-environments
response → environment → Mobile key
Client-side (browser) projects: The LaunchDarkly value is still the Client-side ID. In 
.env
, use a name the bundler exposes to client code:
Stack
.env
key		Read in code
Create React App
REACT_APP_LAUNCHDARKLY_CLIENT_SIDE_ID
process.env.REACT_APP_LAUNCHDARKLY_CLIENT_SIDE_ID
Vite
VITE_LAUNCHDARKLY_CLIENT_SIDE_ID
import.meta.env.VITE_LAUNCHDARKLY_CLIENT_SIDE_ID
Next.js
NEXT_PUBLIC_LAUNCHDARKLY_CLIENT_SIDE_ID
process.env.NEXT_PUBLIC_LAUNCHDARKLY_CLIENT_SIDE_ID
Other stacks may use different prefixes or plain 
LAUNCHDARKLY_CLIENT_SIDE_ID
-- match what the project already uses for public env vars.
SDK类型典型变量名称LaunchDarkly中的来源
服务端
LAUNCHDARKLY_SDK_KEY
get-environments
响应 → 环境 → SDK密钥
客户端符合逻辑/打包器前缀的名称（见下文）
get-environments
响应 → 环境 → 客户端ID
移动
LAUNCHDARKLY_MOBILE_KEY
get-environments
响应 → 环境 → 移动密钥
**客户端（浏览器）项目：**LaunchDarkly中的值仍是客户端ID。在
.env
中使用打包器暴露给客户端代码的名称：
技术栈
.env
密钥		代码中读取方式
Create React App
REACT_APP_LAUNCHDARKLY_CLIENT_SIDE_ID
process.env.REACT_APP_LAUNCHDARKLY_CLIENT_SIDE_ID
Vite
VITE_LAUNCHDARKLY_CLIENT_SIDE_ID
import.meta.env.VITE_LAUNCHDARKLY_CLIENT_SIDE_ID
Next.js
NEXT_PUBLIC_LAUNCHDARKLY_CLIENT_SIDE_ID
process.env.NEXT_PUBLIC_LAUNCHDARKLY_CLIENT_SIDE_ID
其他技术栈可能使用不同前缀或直接使用
LAUNCHDARKLY_CLIENT_SIDE_ID
——匹配项目中已有的公共环境变量命名方式。

Write to 
.env
(when the user consents)

当用户同意时写入
.env
文件

Use the integration root for the file path (repo root or the target package in a monorepo -- see Detect repository stack).
  1. Create or update 
    .env
    :     If 
    .env
    does not exist, create it. If it exists, append or update only the LaunchDarkly lines -- do not remove unrelated variables.
  2. Add what the integration needs:
    • Server-only: 
      LAUNCHDARKLY_SDK_KEY=...
    • Client/browser: the client-side ID under the correct bundler-prefixed key (e.g. 
      VITE_LAUNCHDARKLY_CLIENT_SIDE_ID=...
      ).
    • Full-stack or hybrid (e.g. Next.js, SSR + client): add both the server SDK key and the client-side ID lines when both SDKs are in use.
    • Mobile: 
      LAUNCHDARKLY_MOBILE_KEY=...
      when applicable.
  3. .gitignore
    :     Ensure 
    .env
    is listed in 
    .gitignore
    at the same root where you created 
    .env
    (or the nearest relevant ignore file in a monorepo). If the entry is missing, add it -- only after the user has agreed to repo changes (same permission scope as writing 
    .env
    ). Do not commit files that contain real secrets.
  4. .env.example
    / 
    .env.sample
    :     If the project uses one, add placeholder entries only (no real keys), so teammates know which variables to set.
If the project does not use dotenv and relies on a config module or hosted secrets, follow existing patterns there instead -- the same D7 consent above still applies before writing real values into any file.
使用集成根目录作为文件路径（仓库根目录或单体仓库中的目标包——见检测仓库技术栈）。
  1. **创建或更新
    .env
    ：**如果
    .env
    不存在，则创建它。如果已存在，仅追加或更新LaunchDarkly相关行——不要删除无关变量。
  2. 添加集成所需内容：
    • 仅服务端：
      LAUNCHDARKLY_SDK_KEY=...
    • 客户端/浏览器：将客户端ID添加到正确的打包器前缀密钥下（例如
      VITE_LAUNCHDARKLY_CLIENT_SIDE_ID=...
      ）。
    • 全栈或混合（如Next.js、SSR+客户端）：当同时使用两个SDK时，添加服务端SDK密钥和客户端ID两行。
    • 移动：适用时添加
      LAUNCHDARKLY_MOBILE_KEY=...
      。
  3. **
    .gitignore
    ：**确保
    .env
    已添加到创建
    .env
    的同一根目录下的
    .gitignore
    中（或单体仓库中最近的相关忽略文件）。如果缺少该条目，则添加它——仅在用户同意仓库变更后执行（与写入
    .env
    的权限范围相同）。请勿提交包含真实密钥的文件。
  4. .env.example
    /
    .env.sample
    ：如果项目使用此类文件，仅添加占位符    条目（无真实密钥），以便团队成员知道需要设置哪些变量。
如果项目不使用dotenv，而是依赖配置模块或托管密钥，则遵循现有模式——写入真实值到任何文件前，仍需获得上述D7许可。

Step 3: Add SDK initialization code

步骤3：添加SDK初始化代码

Initialization shape depends on which SDK was chosen during detection and planning. This skill does not include copy-paste samples per SDK -- using the wrong snippet (e.g. React Web when the recipe is Node server) will mislead you.
Source of truth (use in order, repeat per track when dual-SDK):
  1. SDK recipes -- the row for this track's SDK: install is Step 1 above; for init, follow the SDK detail / doc links listed there.
  2. SDK detail files under 
    snippets/
     (when linked from the recipe) -- curated links and, for many SDKs, a full onboarding sample aligned with that SDK.
  3. LaunchDarkly's official docs for that SDK (URLs from the recipe or detail file) -- use their entrypoint and async patterns (e.g. React Web: React Web SDK).
Wire credentials using Step 2: server SDKs use 
LAUNCHDARKLY_SDK_KEY
; client/browser SDKs use the client-side ID with the bundler-prefixed env names from Step 2 where applicable.
Add imports and init to the application entrypoint for that track (or the target package's entrypoint in a monorepo -- see Detect repository stack). Dual SDK: server init goes in the server entrypoint from the plan; client/provider init goes in the client entrypoint -- never a single shared block that pretends to cover both unless the official docs for that stack explicitly prescribe one pattern for both.
初始化形式取决于检测和规划阶段选择的SDK。本技能不包含各SDK的复制粘贴示例——使用错误的代码片段（例如在Node服务端使用React Web的代码）会导致错误。
真实参考依据（按顺序使用，双SDK时每个轨道重复执行）：
  1. SDK指南——对应此轨道SDK的行：安装为上述步骤1；初始化请遵循其中列出的SDK详情/文档链接。
  2. snippets/下的SDK详情文件（当指南中链接到这些文件时）——精选链接，且对于许多SDK，包含与该SDK对齐的完整入门示例。
  3. LaunchDarkly官方文档（来自指南或详情文件的URL）——使用其入口点和异步模式（例如React Web：React Web SDK）。
使用步骤2中的凭证：服务端SDK使用
LAUNCHDARKLY_SDK_KEY
；客户端/浏览器SDK使用客户端ID，并适用步骤2中指定的打包器前缀环境变量名称。
将导入和初始化代码添加到对应轨道的应用入口点（或单体仓库中目标包的入口点——见检测仓库技术栈）。双SDK：服务端初始化代码放入方案中的服务端入口点；客户端/提供者初始化代码放入客户端入口点——除非该技术栈的官方文档明确规定了同时覆盖两者的单一模式，否则绝不要使用单个共享代码块假装覆盖两个轨道。

Key principles

核心原则

  1. Import at the top of the file with other imports
  2. Initialize early in the application lifecycle for that runtime (Node server vs browser)
  3. Wait for initialization before evaluating flags when the SDK supports it
  4. Handle errors -- log failures but don't crash the application
  5. Match existing code style -- same patterns (async/await, callbacks, modules CommonJS vs ESM) as the rest of the codebase
  6. Use the right pattern per surface -- server-side init from the server recipe in server code; client/provider init from the client recipe in client code. Do not reuse one snippet for both tracks or skip the second track's init when the plan is dual-SDK.
  1. 在文件顶部导入，与其他导入放在一起
  2. 在对应运行时的应用生命周期早期初始化（Node服务端 vs 浏览器）
  3. 当SDK支持时，等待初始化完成后再评估标志
  4. 处理错误——记录失败但不要导致应用崩溃
  5. 匹配现有代码风格——使用与代码库其他部分相同的模式（async/await、回调、CommonJS vs ESM模块）
  6. 根据场景使用正确模式——服务端代码使用服务端指南中的服务端初始化代码；客户端代码使用客户端指南中的客户端/提供者初始化代码。当方案为双SDK时，不要为两个轨道重复使用同一个代码片段，也不要跳过第二个轨道的初始化。

Step 4: Verify the code compiles

步骤4：验证代码可编译

After making changes:
  1. Run the project's build or compile step
  2. Run the linter if one is configured
  3. Fix any import errors or type issues without upgrading unrelated dependencies unless the user approved that scope (Permission before changing other dependencies)
Do not proceed to the next step if the code doesn't compile.
Upon completion: Start the application
完成变更后：
  1. 运行项目的构建或编译步骤
  2. 如果配置了代码检查工具，运行它
  3. 修复任何导入错误或类型问题但不要升级无关依赖，除非用户已批准该范围的变更（修改其他依赖前需获得权限）
如果代码无法编译，请勿继续下一步。
完成后：启动应用",