Update to LaunchDarkly

{
  "name": "launchdarkly-flag-create",
  "description": "Create and configure LaunchDarkly feature flags in a way that fits the existing codebase. Use when the user wants to create a new flag, wrap code in a flag, add a feature toggle, or set up an experiment. Guides exploration of existing patterns before creating.",
  "included_files": [
    {
      "relative_path": "README.md",
      "size_in_bytes": 1778
    },
    {
      "relative_path": "marketplace.json",
      "size_in_bytes": 530
    },
    {
      "relative_path": "references/flag-types.md",
      "size_in_bytes": 4709
    },
    {
      "relative_path": "references/sdk-evaluation-patterns.md",
      "size_in_bytes": 6995
    }
  ],
  "skill_md_contents": "---\nname: launchdarkly-flag-create\ndescription: \"Create and configure LaunchDarkly feature flags in a way that fits the existing codebase. Use when the user wants to create a new flag, wrap code in a flag, add a feature toggle, or set up an experiment. Guides exploration of existing patterns before creating.\"\nlicense: Apache-2.0\ncompatibility: Requires the remotely hosted LaunchDarkly MCP server\nmetadata:\n  author: launchdarkly\n  version: \"1.1.0-experimental\"\n---\n\n# LaunchDarkly Flag Create & Configure\n\nYou'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.\n\n## Prerequisites\n\nThis skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.\n\n**Required MCP tools:**\n- `create-flag`: create a new feature flag in a project\n- `get-flag`: verify the flag was created correctly\n\n**Optional MCP tools (enhance workflow):**\n- `list-flags`: browse existing flags to understand naming conventions and tags\n- `update-flag-settings`: update flag metadata (name, description, tags, temporary/permanent status)\n\n## Workflow\n\n### Step 1: Explore the Codebase\n\nBefore creating anything, understand how this codebase uses feature flags.\n\n1. **Find the SDK.** Search for LaunchDarkly SDK imports or initialization:\n   - Look for `launchdarkly`, `ldclient`, `ld-client`, `LDClient` in imports\n   - Check `package.json`, `requirements.txt`, `go.mod`, `Gemfile`, or equivalent for the SDK dependency\n   - Identify which SDK is in use (server-side Node, React, Python, Go, Java, etc.)\n\n2. **Find existing flag evaluations.** Search for variation calls to understand the patterns this codebase uses:\n   - Direct SDK calls: `variation()`, `boolVariation()`, `useFlags()`, etc.\n   - Wrapper patterns: Does this codebase abstract flags behind a service or utility?\n   - Constant definitions: Are flag keys defined as constants somewhere?\n   - See [SDK Evaluation Patterns](references/sdk-evaluation-patterns.md) for patterns by language\n\n3. **Understand conventions.** Look at existing flags to learn:\n   - **Naming convention**: Are keys `kebab-case`, `snake_case`, `camelCase`?\n   - **Organization**: Are flag keys co-located with features, or centralized in a constants file?\n   - **Default values**: What defaults do existing evaluations use?\n   - **Context/user construction**: How does this codebase build the user/context object passed to the SDK? This determines which context kinds and attributes any future targeting can use — and it differs by surface (server vs client vs anonymous). See [Context Availability](../launchdarkly-flag-targeting/references/context-availability.md) before planning a rule, individual target, or rollout.\n\n4. **Check LaunchDarkly project conventions.** Optionally use `list-flags` to see existing flags:\n   - What tags are commonly used?\n   - Are flags marked as temporary or permanent?\n   - What naming patterns exist in the project?\n\n### Step 2: Determine the Right Flag Type\n\nBased on what the user needs, choose the appropriate flag configuration. See [Flag Types and Patterns](references/flag-types.md) for the full guide.\n\n**Quick decision:**\n\n| User intent | Flag kind | Variations |\n|-------------|-----------|------------|\n| \"Toggle a feature on/off\" | `boolean` | `true` / `false` |\n| \"Gradually roll out a feature\" | `boolean` | `true` / `false` |\n| \"A/B test between options\" | `multivariate` (string) | User-defined values |\n| \"Configure a numeric threshold\" | `multivariate` (number) | User-defined values |\n| \"Serve different config objects\" | `multivariate` (JSON) | User-defined values |\n\n**Defaults to apply:**\n- 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.\n- 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.\n- Suggest relevant tags based on the feature area, team, or context the user mentions.\n\n### Step 3: Create the Flag in LaunchDarkly\n\nUse `create-flag` with the configuration determined in Step 2.\n\nAfter creation:\n- The flag is created with **targeting OFF** in all environments.\n- The flag serves the `offVariation` to everyone until targeting is turned on.\n- Remind the user they'll need to use the [flag targeting skill](../launchdarkly-flag-targeting/SKILL.md) to toggle it on and optionally set up rollout rules.\n\n### Step 4: Add Flag Evaluation to Code\n\nNow add the code to evaluate the flag, **matching the patterns you found in Step 1**.\n\n1. **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.\n2. **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.\n3. **Add the conditional logic.** Wrap the new behavior in a flag check.\n4. **Handle both branches.** Make sure the code path for each variation is clear and complete.\n\nSee [SDK Evaluation Patterns](references/sdk-evaluation-patterns.md) for implementation examples by language and framework.\n\n### Step 5: Verify\n\nConfirm the flag is properly set up:\n\n1. **Code compiles/passes linting.** Run the project's build or lint step.\n2. **Flag exists in LaunchDarkly.** Use `get-flag` to confirm it was created with the right configuration.\n3. **Both code paths work.** The flag-off path preserves existing behavior; the flag-on path enables the new feature.\n4. **Default value is safe.** If LaunchDarkly is unreachable, the code falls back to the default: make sure that's the existing/safe behavior.\n\n## Updating Flag Settings\n\nIf the user wants to change flag metadata (not targeting), use `update-flag-settings`. Supported changes:\n\n| Change | Instruction |\n|--------|-------------|\n| Rename | `{kind: \"updateName\", value: \"New Name\"}` |\n| Update description | `{kind: \"updateDescription\", value: \"New description\"}` |\n| Add tags | `{kind: \"addTags\", values: [\"tag1\", \"tag2\"]}` |\n| Remove tags | `{kind: \"removeTags\", values: [\"old-tag\"]}` |\n| Mark as temporary | `{kind: \"markTemporary\"}` |\n| Mark as permanent | `{kind: \"markPermanent\"}` |\n\nMultiple instructions can be batched in a single call. These changes are project-wide, not environment-specific.\n\n**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](../launchdarkly-flag-targeting/SKILL.md).\n\n## Important Context\n\n- **Flag keys are immutable.** Once created, a flag's key cannot be changed. Choose carefully.\n- **Flags start OFF.** Creation never enables a flag. This is a safety feature.\n- **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.\n- **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.\n\n## References\n\n- [Flag Types and Patterns](references/flag-types.md): Boolean vs multivariate, naming conventions, configuration best practices\n- [SDK Evaluation Patterns](references/sdk-evaluation-patterns.md): How to evaluate flags in each SDK, including common wrapper patterns\n- [Context Availability](../launchdarkly-flag-targeting/references/context-availability.md): Which context kinds/attributes targeting can use, matched to the surface where the flag is read (relevant once the flag will target rather than being a plain on/off switch)\n"
}