Onboarding
Ship your first LaunchDarkly boolean flag end-to-end—create the flag, wire evaluation, and prove OFF then ON after the SDK is installed.
Overview
LaunchDarkly onboarding (first-flag) is an agent skill for the Ship phase that creates a boolean first flag and verifies OFF-then-ON evaluation after SDK setup.
Install
npx skills add https://github.com/launchdarkly/agent-skills --skill onboardingWhat is this skill?
- Parent LaunchDarkly onboarding Step 6: create first feature flag after sdk-install apply
- Mandatory flow: default off, verify OFF, toggle on, verify ON (Steps 3–5 in skill body)
- Supports MCP, LaunchDarkly API, or ldcli with env-based LAUNCHDARKLY_ACCESS_TOKEN—never literal tokens in commands
- Optional handoff to launchdarkly-flag-create from launchdarkly/ai-tooling for flag creation and repo-matched evaluation
- Full fallback instructions when the flag-create skill or MCP-only paths are unavailable
- LaunchDarkly parent onboarding Step 6 (first flag)
- Verification sequence: default off, verify OFF, toggle on, verify ON
Adoption & trust: 2k installs on skills.sh; 16 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your LaunchDarkly SDK is installed but you still lack a working flag and proof that evaluation changes when you toggle remotely.
Who is it for?
Indie devs finishing LaunchDarkly onboarding who need MCP, API, or ldcli steps with a enforced verify-off-verify-on gate.
Skip if: Teams without LaunchDarkly project access, without completing parent Step 5 SDK install, or who only need flag design docs with no runtime proof.
When should I use this skill?
SDK is installed (parent Step 5) and you need to create a boolean first flag with end-to-end OFF/ON evaluation proof via MCP, API, or ldcli.
What do I get? / Deliverables
You end with a boolean flag, evaluation in the repo, and documented OFF and ON checks so you can ship controlled releases instead of hard-coded feature branches.
- Created boolean feature flag with safe default off
- Evaluation code aligned to the repo
- Documented OFF and ON verification results
Recommended Skills
Journey fit
Ship is the right shelf because this is onboarding Step 6: the SDK is already connected and the goal is launch-safe toggling with verified evaluation behavior. Launch subphase fits first-flag proof and controlled rollouts immediately before or during releasing user-visible behavior.
How it compares
Use as a guided Ship workflow after sdk-install apply, not as a standalone MCP server catalog entry.
Common Questions / FAQ
Who is LaunchDarkly onboarding for?
Builders using Claude Code or compatible agents who already applied LaunchDarkly SDK changes and need Step 6 first-flag verification in their own project.
When should I use LaunchDarkly onboarding?
Use it in Ship during launch prep right after sdk-install apply, before wider rollout, when you need end-to-end boolean flag proof in your environment.
Is LaunchDarkly onboarding safe to install?
It requires LaunchDarkly credentials via environment variables only; review the Security Audits panel on this Prism page and rotate tokens if they ever appeared in chat logs.
Workflow Chain
Then invoke: launchdarkly flag create
SKILL.md
READMESKILL.md - Onboarding
# Create first feature flag The SDK is connected. Now help the user create their first feature flag and see it work end-to-end. This skill is nested under [LaunchDarkly onboarding](../SKILL.md); the parent **Step 6** is **first flag**. **Prior:** [Apply code changes](../sdk-install/apply/SKILL.md). **Optional -- Flag Create skill already installed:** If the **`launchdarkly-flag-create`** skill from [github.com/launchdarkly/ai-tooling](https://github.com/launchdarkly/ai-tooling) is available in the session (install with `npx skills add launchdarkly/ai-tooling --skill launchdarkly-flag-create -y --agent <agent>`), you may use it for **creating the flag** and **choosing evaluation code** that matches the repo. You must still complete **default off -> verify OFF -> toggle on -> verify ON** (Steps 3-5 below). **Do not** require that skill: this page stays the full fallback when it is missing or MCP-only flows conflict with the user's setup. ## Security: Credential handling **Never substitute literal token values into commands.** Use environment variable references instead: - Shell commands: `$LAUNCHDARKLY_ACCESS_TOKEN` (expanded by the shell, not visible in `ps` output) - Set the variable in your session: `export LAUNCHDARKLY_ACCESS_TOKEN=<your-token>` This prevents tokens from appearing in process lists, shell history, and screen recordings. ## Step 0: Consult SDK flag-key guidance Before creating the flag or wiring evaluation code, check the [Flag key behavior by SDK](#flag-key-behavior-by-sdk) table below. Some SDKs transform flag keys before exposing them in application code (e.g. the React SDK camelCases kebab-case keys). The flag key you create in LaunchDarkly, the SDK/framework configuration, and the key you reference in code must all align. - **If the SDK transforms keys** (e.g. React `useFlags()` camelCases `my-first-flag` → `myFirstFlag`): generate evaluation code using the **transformed** key. The flag key in LaunchDarkly stays as-is (kebab-case is conventional). - **If the SDK preserves keys as-is** (most server-side SDKs): use the exact LaunchDarkly flag key string in code. - **If the SDK supports both modes** (e.g. React allows disabling camelCase via provider options): decide which mode the project uses (check existing code or provider config), then generate code that matches. ### Flag key behavior by SDK | SDK | Key transformation | Code key for `my-first-flag` | Notes | |-----|--------------------|------------------------------|-------| | React Web (`useFlags()`) | camelCase by default | `myFirstFlag` | `reactOptions: { useCamelCaseFlagKeys: false }` on the provider disables this | | React Native (`useFlags()`) | camelCase by default | `myFirstFlag` | Same `reactOptions` override available | | Vue (`useLDFlag()`) | None (pass original key) | `'my-first-flag'` | | | JavaScript Browser | None | `'my-first-flag'` | | | Node.js Server | None | `'my-first-flag'` | | | Python Server | None | `'my-first-flag'` | | | Go Server | None | `"my-first-flag"` | | | Java Server | None | `"my-first-flag"` | | | .NET Server | None | `"my-first-flag"` | | | Ruby Server | None | `'my-first-flag'` | | | Swift/iOS | None | `"my-first-flag"` | | | Android | None | `"my-first-flag"` | | | Flutter | None | `'my-first-flag'` | | When wiring the evaluation code in Step 2 below, use the **Code key** column value, not the raw LaunchDarkly key, whenever the SDK applies a transformation. ## Step 1: Create the flag **REST / curl auth:** Use `$LAUNCHDARKLY_ACCESS_TOKEN` as the `Authorization` header value (LaunchDarkly uses the raw token, no `Bearer` prefix). The shell expands th