launchdarkly-flag-create

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

LaunchDarkly Flag Create & Configure

LaunchDarkly 标志创建与配置

You're using a skill that will guide you through introducing a new feature flag into a codebase. Your job is to explore how flags are already used in this codebase, create the flag in LaunchDarkly in a way that fits, add the evaluation code matching existing patterns, and verify everything is wired up correctly.

你正在使用一项技能，它将引导你在代码库中引入新的功能标志。你的任务是探索此代码库中标志的现有使用方式，以适配的方式在LaunchDarkly中创建标志，添加符合现有模式的评估代码，并验证所有配置是否正确连接。

Prerequisites

前提条件

This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.

Required MCP tools:

```
create-flag
```
— create a new feature flag in a project
```
get-flag
```
— verify the flag was created correctly

Optional MCP tools (enhance workflow):

```
list-flags
```
— browse existing flags to understand naming conventions and tags
```
update-flag-settings
```
— update flag metadata (name, description, tags, temporary/permanent status)

此技能要求你的环境中已配置远程托管的LaunchDarkly MCP服务器。

必需的MCP工具：

```
create-flag
```
— 在项目中创建新的功能标志
```
get-flag
```
— 验证标志是否正确创建

可选MCP工具（优化工作流）：

```
list-flags
```
— 浏览现有标志以了解命名规范和标签
```
update-flag-settings
```
— 更新标志元数据（名称、描述、标签、临时/永久状态）

Workflow

工作流

Step 1: Explore the Codebase

步骤1：探索代码库

Before creating anything, understand how this codebase uses feature flags.

Find the SDK. Search for LaunchDarkly SDK imports or initialization:
- Look for
```
launchdarkly
```
  ,
```
ldclient
```
  ,
```
ld-client
```
  ,
```
LDClient
```
  in imports
- Check
```
package.json
```
  ,
```
requirements.txt
```
  ,
```
go.mod
```
  ,
```
Gemfile
```
  , or equivalent for the SDK dependency
- Identify which SDK is in use (server-side Node, React, Python, Go, Java, etc.)
Find existing flag evaluations. Search for variation calls to understand the patterns this codebase uses:
- Direct SDK calls:
```
variation()
```
  ,
```
boolVariation()
```
  ,
```
useFlags()
```
  , etc.
- Wrapper patterns: Does this codebase abstract flags behind a service or utility?
- Constant definitions: Are flag keys defined as constants somewhere?
- See SDK Evaluation Patterns for patterns by language
Understand conventions. Look at existing flags to learn:
- Naming convention: Are keys
```
kebab-case
```
  ,
```
snake_case
```
  ,
```
camelCase
```
  ?
- Organization: Are flag keys co-located with features, or centralized in a constants file?
- Default values: What defaults do existing evaluations use?
- Context/user construction: How does this codebase build the user/context object passed to the SDK?
Check LaunchDarkly project conventions. Optionally use
```
list-flags
```
to see existing flags:
- What tags are commonly used?
- Are flags marked as temporary or permanent?
- What naming patterns exist in the project?

在创建任何内容之前，先了解此代码库如何使用功能标志。

查找SDK：搜索LaunchDarkly SDK的导入或初始化代码：
- 在导入语句中查找
```
launchdarkly
```
  、
```
ldclient
```
  、
```
ld-client
```
  、
```
LDClient
```
- 查看
```
package.json
```
  、
```
requirements.txt
```
  、
```
go.mod
```
  、
```
Gemfile
```
  或等效文件中的SDK依赖
- 确定正在使用的SDK类型（服务端Node、React、Python、Go、Java等）
查找现有标志评估代码：搜索variation调用以了解此代码库使用的模式：
- 直接SDK调用：
```
variation()
```
  、
```
boolVariation()
```
  、
```
useFlags()
```
  等
- 封装模式：此代码库是否将标志抽象到服务或工具类之后？
- 常量定义：标志键是否在某个地方定义为常量？
- 查看SDK评估模式了解各语言的模式示例
了解规范：查看现有标志以学习：
- 命名规范：键是使用
```
kebab-case
```
  、
```
snake_case
```
  还是
```
camelCase
```
  ？
- 组织方式：标志键是与功能代码共存，还是集中在常量文件中？
- 默认值：现有评估使用的默认值是什么？
- 上下文/用户构造：此代码库如何构建传递给SDK的用户/上下文对象？
查看LaunchDarkly项目规范：可选择使用
```
list-flags
```
查看现有标志：
- 常用的标签有哪些？
- 标志是否标记为临时或永久？
- 项目中存在哪些命名模式？

Step 2: Determine the Right Flag Type

步骤2：确定合适的标志类型

Based on what the user needs, choose the appropriate flag configuration. See Flag Types and Patterns for the full guide.

Quick decision:

User intent	Flag kind	Variations
"Toggle a feature on/off"	`boolean`	`true` / `false`
"Gradually roll out a feature"	`boolean`	`true` / `false`
"A/B test between options"	`multivariate` (string)	User-defined values
"Configure a numeric threshold"	`multivariate` (number)	User-defined values
"Serve different config objects"	`multivariate` (JSON)	User-defined values

Defaults to apply:

Set
```
temporary: true
```
unless the user explicitly says this is a permanent/long-lived flag. Most flags are release flags that should eventually be cleaned up.
Generate a
```
key
```
from the name if not provided (e.g., "New Checkout Flow" →
```
new-checkout-flow
```
), but match the codebase's naming convention if one exists.
Suggest relevant tags based on the feature area, team, or context the user mentions.

根据用户需求，选择合适的标志配置。查看标志类型与模式获取完整指南。

快速决策参考：

用户意图	标志类型	变体选项
"开启/关闭某个功能"	`boolean`	`true` / `false`
"逐步推出某个功能"	`boolean`	`true` / `false`
"在多个选项间进行A/B测试"	`multivariate` （字符串类型）	用户自定义值
"配置数值阈值"	`multivariate` （数值类型）	用户自定义值
"提供不同的配置对象"	`multivariate` （JSON类型）	用户自定义值

默认配置规则：

除非用户明确说明这是永久/长期标志，否则设置
```
temporary: true
```
。大多数标志是发布标志，最终需要被清理。
如果未提供键，则从名称生成（例如"New Checkout Flow" →
```
new-checkout-flow
```
），但如果代码库已有命名规范，则遵循该规范。
根据用户提到的功能领域、团队或上下文，建议相关标签。

Step 3: Create the Flag in LaunchDarkly

步骤3：在LaunchDarkly中创建标志

Use

create-flag

with the configuration determined in Step 2.

After creation:

The flag is created with targeting OFF in all environments.
The flag serves the
```
offVariation
```
to everyone until targeting is turned on.
Remind the user they'll need to use the flag targeting skill to toggle it on and optionally set up rollout rules.

使用

create-flag

工具，按照步骤2确定的配置创建标志。

创建完成后：

标志在所有环境中的目标状态为关闭。
在开启目标配置前，标志会向所有用户返回
```
offVariation
```
的值。
提醒用户需要使用标志目标配置技能来开启标志，并可选择设置推出规则。

Step 4: Add Flag Evaluation to Code

步骤4：向代码中添加标志评估逻辑

Now add the code to evaluate the flag, matching the patterns you found in Step 1.

Use the same SDK patterns the codebase already uses. If there's a wrapper, use the wrapper. If there are constants, add the new key to the constants file.
Use an appropriate default value. The default (fallback) value in code should be the "safe" behavior — typically the existing behavior before the flag. This ensures the feature stays off if the SDK can't reach LaunchDarkly.
Add the conditional logic. Wrap the new behavior in a flag check.
Handle both branches. Make sure the code path for each variation is clear and complete.

See SDK Evaluation Patterns for implementation examples by language and framework.

现在添加标志评估代码，必须与步骤1中发现的模式保持一致。

使用代码库已有的SDK模式：如果存在封装工具类，使用该工具类；如果有常量文件，将新键添加到常量文件中。
使用合适的默认值：代码中的默认（回退）值应是"安全"行为 —— 通常是添加标志前的现有行为。这样可以确保如果SDK无法连接到LaunchDarkly，功能仍保持关闭状态。
添加条件逻辑：将新行为包裹在标志检查中。
处理两个分支：确保每个变体对应的代码路径清晰且完整。

查看SDK评估模式获取各语言和框架的实现示例。

Step 5: Verify

步骤5：验证

Confirm the flag is properly set up:

Code compiles/passes linting. Run the project's build or lint step.
Flag exists in LaunchDarkly. Use
```
get-flag
```
to confirm it was created with the right configuration.
Both code paths work. The flag-off path preserves existing behavior; the flag-on path enables the new feature.
Default value is safe. If LaunchDarkly is unreachable, the code falls back to the default — make sure that's the existing/safe behavior.

确认标志已正确配置：

代码编译/通过语法检查：运行项目的构建或语法检查步骤。
标志在LaunchDarkly中存在：使用
```
get-flag
```
工具确认标志已按正确配置创建。
两个代码路径均正常工作：标志关闭时保留现有行为；标志开启时启用新功能。
默认值安全可靠：如果无法连接到LaunchDarkly，代码会回退到默认值 —— 确保该值是现有/安全的行为。

Updating Flag Settings

更新标志设置

If the user wants to change flag metadata (not targeting), use

update-flag-settings

. Supported changes:

Change	Instruction
Rename	`{kind: "updateName", value: "New Name"}`
Update description	`{kind: "updateDescription", value: "New description"}`
Add tags	`{kind: "addTags", values: ["tag1", "tag2"]}`
Remove tags	`{kind: "removeTags", values: ["old-tag"]}`
Mark as temporary	`{kind: "markTemporary"}`
Mark as permanent	`{kind: "markPermanent"}`

Multiple instructions can be batched in a single call. These changes are project-wide, not environment-specific.

Important: Metadata updates (above) are separate from targeting changes (toggle, rollout, rules). If the user wants to change who sees what, direct them to the flag targeting skill.

如果用户需要更改标志元数据（非目标配置），使用

update-flag-settings

工具。支持的更改包括：

更改类型	指令格式
重命名	`{kind: "updateName", value: "New Name"}`
更新描述	`{kind: "updateDescription", value: "New description"}`
添加标签	`{kind: "addTags", values: ["tag1", "tag2"]}`
删除标签	`{kind: "removeTags", values: ["old-tag"]}`
标记为临时	`{kind: "markTemporary"}`
标记为永久	`{kind: "markPermanent"}`

可在单次调用中批量执行多个指令。这些更改是项目级的，而非环境特定的。

重要提示： 元数据更新（如上）与目标配置更改（开启/关闭、推出规则、自定义规则）是分开的。如果用户需要更改目标受众，引导其使用标志目标配置技能。

Important Context

重要说明

Flag keys are immutable. Once created, a flag's key cannot be changed. Choose carefully.
Flags start OFF. Creation never enables a flag. This is a safety feature.
The default value in code is your safety net. It's what gets served when the SDK can't connect to LaunchDarkly. Always use the "safe" / existing behavior as the default.
Follow existing codebase conventions. The most common mistake is introducing a flag pattern that doesn't match what the team already does. Step 1 exists to prevent this.

标志键不可变：创建后，标志的键无法更改，请谨慎选择。
标志默认关闭：创建操作不会自动启用标志，这是一项安全机制。
代码中的默认值是安全保障：当SDK无法连接到LaunchDarkly时，会使用此值。始终将"安全"的现有行为设为默认值。
遵循代码库现有规范：最常见的错误是引入与团队现有模式不符的标志用法。步骤1的存在就是为了避免这种情况。

References

参考资料

Flag Types and Patterns — Boolean vs multivariate, naming conventions, configuration best practices
SDK Evaluation Patterns — How to evaluate flags in each SDK, including common wrapper patterns

标志类型与模式 — 布尔型与多变量型标志对比、命名规范、配置最佳实践
SDK评估模式 — 各SDK的标志评估方式，包括常见的封装模式",