plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Generate integration plan (SDK install)

生成集成方案（SDK安装）

Based on what you detected, choose the right SDK and plan the minimal set of changes needed.

This skill is nested under LaunchDarkly SDK Install (onboarding); the parent Step 2 is plan. Prior: Detect repository stack. Next: Apply code changes.

根据检测到的技术栈，选择合适的SDK并规划所需的最小修改集。

此技能隶属于LaunchDarkly SDK 安装（入门）；父流程的步骤2为方案规划。前置步骤：检测代码库技术栈。后续步骤：应用代码变更。

Choose the right SDK

选择合适的SDK

Use the SDK recipes reference to match the detected stack to an SDK. Start with Top 10 SDKs (start here) in that file for common stacks; use the (other) sections for less common SDKs.

The key decision:

Project Type	SDK Type	Key Type
Backend API, server-rendered app, CLI tool	Server-side SDK	SDK Key
Browser SPA (React, Vue, Angular, vanilla JS)	Client-side SDK	Client-side ID
iOS or Android native app	Mobile SDK	Mobile Key
React Native	Mobile SDK	Mobile Key
Flutter (iOS, Android, or desktop app targets)	Client-side SDK (Flutter)	Mobile Key
Flutter web	Client-side SDK (Flutter)	Client-side ID
Electron desktop app	Client-side SDK (Node.js)	Client-side ID
Cloudflare Workers, Vercel Edge, AWS Lambda@Edge	Edge SDK	SDK Key
.NET client (MAUI, Xamarin, WPF, UWP)	Mobile SDK (.NET)	Mobile Key
C/C++ client application	Client-side SDK (C/C++)	Mobile Key
C/C++ server application	Server-side SDK (C/C++)	SDK Key
Haskell server	Server-side SDK (Haskell)	SDK Key
Lua server	Server-side SDK (Lua)	SDK Key
Roku (BrightScript)	Client-side SDK (Roku)	Mobile Key

For every supported SDK, package name, install hint, and official Docs link, use SDK recipes and the linked files under

snippets/

使用SDK 参考指南将检测到的技术栈匹配至对应的SDK。先从该文件中的**Top 10 SDKs（从这里开始）部分选择常见技术栈对应的SDK；对于不太常见的技术栈，使用(other)**部分的内容。

核心决策规则：

项目类型	SDK类型	密钥类型
后端API、服务端渲染应用、CLI工具	服务端SDK	SDK密钥
浏览器SPA（React、Vue、Angular、原生JS）	客户端SDK	客户端ID
iOS或Android原生应用	移动端SDK	移动端密钥
React Native	移动端SDK	移动端密钥
Flutter（iOS、Android或桌面应用目标）	客户端SDK（Flutter）	移动端密钥
Flutter Web	客户端SDK（Flutter）	客户端ID
Electron桌面应用	客户端SDK（Node.js）	客户端ID
Cloudflare Workers、Vercel Edge、AWS Lambda@Edge	边缘SDK	SDK密钥
.NET客户端（MAUI、Xamarin、WPF、UWP）	移动端SDK（.NET）	移动端密钥
C/C++客户端应用	客户端SDK（C/C++）	移动端密钥
C/C++服务端应用	服务端SDK（C/C++）	SDK密钥
Haskell服务端	服务端SDK（Haskell）	SDK密钥
Lua服务端	服务端SDK（Lua）	SDK密钥
Roku（BrightScript）	客户端SDK（Roku）	移动端密钥

如需获取各支持SDK的包名、安装提示及官方文档链接，请参考SDK 参考指南及

snippets/

目录下的关联文件。

Dual SDK integrations

双SDK集成

Use this section when the user asked for both a server-side and a client-side integration, or when the stack clearly needs two LaunchDarkly SDKs (e.g. Next.js with server evaluation and browser UI flags, separate backend + SPA repos in one workspace target, etc.).

Do not "complete" onboarding with a single SDK while hand-waving the second (no second package in

package.json

, no second init path, no second recipe followed). Each SDK is a separate product with its own install command and initialization.

For each of the two SDKs, the plan must spell out (with no gaps):

Server-side track:

Recipe / SDK recipes row or snippet name
Package name(s) (exact artifact)
Install command (full command from recipe)
Dependency file (where the line is added)
Entrypoint file(s) (e.g.
```
instrumentation.ts
```
, API entry,
```
main.py
```
)
Env vars (typically
```
LAUNCHDARKLY_SDK_KEY
```
)
Init summary (where it runs; which doc/snippet)

Client-side track:

Recipe / snippet name (different row than server)
Package name(s) (e.g. React Web vs Node server -- must be the client artifact)
Install command (second command -- never implied)
Dependency file
Entrypoint file(s) (e.g.
```
app/providers.tsx
```
, root layout,
```
main.tsx
```
)
Env vars (bundler-prefixed client-side ID, e.g.
```
NEXT_PUBLIC_...
```
)
Init summary (provider/wrapper/hook from client recipe)

If you cannot name two packages and two entrypoints, you are not done planning -- go back to SDK recipes and detection.

Important distinctions:

Next.js: Server-side SDK for API routes / server components / RSC contexts that evaluate on the server; React client SDK for client components. If the user requested both, the plan lists both tracks in full. If they only want one surface to start, state that explicitly in the plan.
Node.js: If it's a backend service (Express, Fastify, etc.), use the server-side SDK. There is also a Node.js client SDK for desktop/Electron apps.
React: If it's a standalone SPA, use
```
launchdarkly-react-client-sdk
```
. If it's part of Next.js, see above.
.NET: Use the server SDK (
```
LaunchDarkly.ServerSdk
```
) for ASP.NET and backend services. For MAUI, Xamarin, WPF, and UWP, use the .NET mobile SDK (
```
LaunchDarkly.ClientSdk
```
, mobile key) -- SDK recipes -- .NET (Client). Blazor WebAssembly (and other browser-hosted .NET client UI) still uses
```
LaunchDarkly.ClientSdk
```
but with a client-side ID, not a mobile key -- see the same recipe.
Flutter: Use the Flutter client SDK (
```
launchdarkly_flutter_client_sdk
```
-- SDK recipes -- Flutter). Use a mobile key for typical iOS/Android/desktop app builds; use the client-side ID (and the project's pattern for public env vars) for Flutter web. If the user ships multiple targets, confirm which to wire first or plan separate env/config per target.

当用户要求同时集成服务端和客户端SDK，或技术栈明显需要两个LaunchDarkly SDK时（例如，同时使用服务端评估和浏览器UI标识的Next.js应用、同一工作区目标中的独立后端+SPA代码库等），请使用本节内容。

请勿仅用单个SDK完成入门流程，而忽略第二个SDK的集成（如

package.json

中未添加第二个包、未配置第二个初始化路径、未遵循第二个参考指南）。每个SDK都是独立的产品，拥有各自的安装命令和初始化流程。

对于两个SDK中的每一个，方案必须明确列出以下内容（无遗漏）：

服务端流程：

参考指南 / SDK 参考指南中的对应行或代码片段名称
包名（精确的制品名称）
安装命令（来自参考指南的完整命令）
依赖文件（添加依赖的文件）
入口文件（例如
```
instrumentation.ts
```
、API入口、
```
main.py
```
）
环境变量（通常为
```
LAUNCHDARKLY_SDK_KEY
```
）
初始化概述（运行位置；对应的文档/代码片段）

客户端流程：

参考指南/代码片段名称（与服务端对应的行不同）
包名（例如React Web与Node服务端——必须是客户端制品）
安装命令（第二条命令——绝不隐含）
依赖文件
入口文件（例如
```
app/providers.tsx
```
、根布局、
```
main.tsx
```
）
环境变量（打包器前缀的客户端ID，例如
```
NEXT_PUBLIC_...
```
）
初始化概述（来自客户端参考指南的提供者/包装器/钩子）

如果无法明确指定两个包和两个入口文件，则方案规划未完成——请回到SDK 参考指南和技术栈检测步骤。

重要区分：

Next.js：服务端SDK用于API路由/服务端组件/RSC上下文（在服务端执行评估）；React客户端SDK用于客户端组件。如果用户要求同时集成两者，方案需完整列出两个流程。如果用户只想先集成其中一个，请在方案中明确说明。
Node.js：如果是后端服务（Express、Fastify等），使用服务端SDK。另有适用于桌面/Electron应用的Node.js客户端SDK。
React：如果是独立SPA，使用
```
launchdarkly-react-client-sdk
```
。如果是Next.js的一部分，请参考上述内容。
.NET：ASP.NET和后端服务使用服务端SDK（
```
LaunchDarkly.ServerSdk
```
）。MAUI、Xamarin、WPF和UWP使用**.NET移动端SDK**（
```
LaunchDarkly.ClientSdk
```
，移动端密钥）——参考SDK参考指南——.NET（客户端）。Blazor WebAssembly（及其他浏览器托管的.NET客户端UI）仍使用
```
LaunchDarkly.ClientSdk
```
，但需使用客户端ID而非移动端密钥——请参考同一参考指南。
Flutter：使用Flutter客户端SDK（
```
launchdarkly_flutter_client_sdk
```
——参考SDK参考指南——Flutter）。典型的iOS/Android/桌面应用构建使用移动端密钥；Flutter Web使用客户端ID（及项目的公共环境变量模式）。如果用户发布多个目标平台，请确认优先配置哪个平台，或为每个平台规划单独的环境/配置。

Plan the changes

规划变更内容

Your integration plan should identify exactly:

你的集成方案应明确确定以下内容：

1. Files to modify

1. 需修改的文件

Use the information gathered during Detect repository stack -- specifically the detected package manager, dependency file, and application entrypoint:

Dependency file: The file identified during detection (e.g.,
```
package.json
```
,
```
requirements.txt
```
,
```
go.mod
```
) -- use the detected package manager to add the SDK
Entrypoint file: The application entrypoint identified during detection -- where SDK initialization code will go. Dual-SDK plans list two entrypoints (see Dual SDK integrations).
Environment/config file: Prefer
```
.env
```
at the integration root for real secrets (create it if it does not exist); ensure
```
.env
```
is listed in
```
.gitignore
```
there. Use
```
.env.example
```
/
```
.env.sample
```
for placeholders only. If the project does not use dotenv, follow its existing config pattern -- see Apply code changes Step 2 for consent, writing keys, and hybrid server+client cases.

使用检测代码库技术栈步骤中收集的信息——特别是检测到的包管理器、依赖文件和应用入口文件：

依赖文件：检测到的文件（例如
```
package.json
```
、
```
requirements.txt
```
、
```
go.mod
```
）——使用检测到的包管理器添加SDK
入口文件：检测到的应用入口文件——SDK初始化代码将放置于此。双SDK方案需列出两个入口文件（参见双SDK集成）。
环境/配置文件：优先在集成根目录使用
```
.env
```
存储真实密钥（若不存在则创建）；确保
```
.env
```
已列入该目录的
```
.gitignore
```
。仅使用
```
.env.example
```
/
```
.env.sample
```
作为占位符。如果项目不使用dotenv，请遵循其现有的配置模式——参考应用代码变更步骤2中的授权、密钥写入及服务端+客户端混合场景说明。

2. Code changes

2. 代码变更

For each SDK in scope (one or two tracks), describe the specific changes:

Add SDK dependency -- the install command from the SDK recipe (repeat for each package when dual-SDK)
Add SDK import -- the import statement at the top of that track's entrypoint
Add SDK initialization -- the init code for that SDK from that recipe/snippet, placed early in the right lifecycle (server vs client)
Configure credentials -- via environment variable, never hardcoded (SDK key vs client-side ID per track)

对于范围内的每个SDK（一个或两个流程），描述具体的变更内容：

添加SDK依赖——来自SDK参考指南的安装命令（双SDK时为每个包重复此步骤）
添加SDK导入——在对应流程的入口文件顶部添加导入语句
添加SDK初始化——来自对应参考指南/代码片段的SDK初始化代码，放置在合适的生命周期早期（服务端 vs 客户端）
配置凭据——通过环境变量配置，绝不硬编码（每个流程对应SDK密钥或客户端ID）

3. Environment variable convention

3. 环境变量约定

Check how the project handles configuration:

.env
: If the stack uses dotenv (or you are introducing it for LaunchDarkly), plan to create
```
.env
```
at the integration root when it is missing, then add
```
LAUNCHDARKLY_SDK_KEY
```
,
```
LAUNCHDARKLY_CLIENT_SIDE_ID
```
/ bundler-prefixed client ID, or
```
LAUNCHDARKLY_MOBILE_KEY
```
as appropriate (see Apply code changes Step 2 for names, consent before real values, and hybrid server+client cases). Plan to verify
```
.gitignore
```
includes
```
.env
```
at that root (add the entry if missing, with the same user permission as other repo edits).
.env.example
/
.env.sample
: If present, plan placeholder entries only (no real secrets).
Config module or
process.env
: If the project does not use
```
.env
```
, plan to follow the existing pattern for secrets.

检查项目的配置处理方式：

**
```
.env
```
：**如果技术栈使用dotenv（或为LaunchDarkly引入dotenv），当
```
.env
```
缺失时，计划在集成根目录创建该文件，然后根据需要添加
```
LAUNCHDARKLY_SDK_KEY
```
、
```
LAUNCHDARKLY_CLIENT_SIDE_ID
```
/ 打包器前缀的客户端ID，或
```
LAUNCHDARKLY_MOBILE_KEY
```
（参考应用代码变更步骤2中的变量名称、真实值获取前的授权及服务端+客户端混合场景说明）。计划验证该根目录的
```
.gitignore
```
是否包含
```
.env
```
（若缺失则添加该条目，权限与其他代码库编辑一致）。
.env.example
/
.env.sample
：如果存在，仅计划添加占位符条目（无真实密钥）。
**配置模块或
```
process.env
```
：**如果项目不使用
```
.env
```
，计划遵循其现有的密钥存储模式。

Present the plan

呈现方案

Before making any changes, summarize the plan to the user.

Single SDK:

Install
```
[package name]
```
using
```
[install command]
```
Add SDK dependency to
```
[dependency file]
```
Add import and initialization to
```
[entrypoint file]
```
Add
```
[env var]
```
to
```
.env
```
(create if missing; real value after user consent)
Ensure
```
.env
```
is in
```
.gitignore
```
Add placeholder to
```
.env.example
```
if the project uses one

Only LaunchDarkly SDK packages will be added unless the user explicitly approves other dependency changes.

Dual SDK: Present the same numbered format separately for each track (e.g. "Server-side:" steps 1-7, then "Client-side:" steps 1-7), following Dual SDK integrations. Do not omit the second track.

After presenting the plan:

D6 -- BLOCKING: Call your structured question tool now.

question: "Here's the integration plan. Does this look right?"
options:
- "Yes, approve and proceed" -> begin applying
- "I'd like to change something" -> let user specify changes
STOP. Do not write the question as text. Do not begin installing packages, writing files, or modifying code until the user selects an option.

If the entrypoint is ambiguous or multiple SDKs could apply, ask those specific questions as part of the plan presentation (each as its own blocking decision point using the same pattern).

Do not ask for SDK keys, client-side IDs, or mobile keys as part of plan confirmation -- the parent flow collects those at Apply code changes. The Key type column above is for technical planning only, not a prompt for secrets.

Do not promise or imply that you will upgrade unrelated dependencies to satisfy the latest SDK -- Apply requires explicit approval before any non-LaunchDarkly package changes.

Upon completion: Apply code changes

在进行任何变更之前，向用户总结方案内容。

单SDK方案：

使用
```
[安装命令]
```
安装
```
[包名]
```
将SDK依赖添加至
```
[依赖文件]
```
在
```
[入口文件]
```
中添加导入和初始化代码
向
```
.env
```
添加
```
[环境变量]
```
（若缺失则创建；获得用户授权后填入真实值）
确保
```
.env
```
已列入
```
.gitignore
```
如果项目使用
```
.env.example
```
，向其中添加占位符

除非用户明确批准，否则仅添加LaunchDarkly SDK包。

双SDK方案： 为每个流程分别使用相同的编号格式呈现（例如“服务端：”步骤1-7，然后“客户端：”步骤1-7），遵循双SDK集成的要求。请勿省略第二个流程。

呈现方案后：

D6 -- 阻塞： 立即调用结构化提问工具。

问题：“这是集成方案，看起来是否正确？”
选项：
- “是的，批准并继续” -> 开始应用变更
- “我想修改一些内容” -> 让用户指定修改内容
停止操作。请勿将问题以文本形式写出。在用户选择选项之前，请勿开始安装包、写入文件或修改代码。

如果入口文件不明确或多个SDK适用，请在方案呈现时提出这些具体问题（每个问题作为独立的阻塞决策点，使用相同的模式）。

请勿在方案确认环节要求用户提供SDK密钥、客户端ID或移动端密钥——父流程会在应用代码变更步骤收集这些信息。上述密钥类型列仅用于技术规划，并非索要密钥的提示。

请勿承诺或暗示会升级无关依赖以适配最新SDK——应用变更步骤要求在修改任何非LaunchDarkly包之前获得明确批准。

完成后： 应用代码变更