LaunchDarkly SDK Onboarding

Orchestrates LaunchDarkly setup in an existing codebase: on kickoff, show a roadmap in chat (see Kickoff: onboarding roadmap); Step 0 writes a living onboarding log so a new session or the user can resume; then explore the project, detect the agent, install flag-management skills, configure the LaunchDarkly MCP server early, install and initialize the SDK (sdk-install and nested detect/plan/apply), and create a first feature flag. Nested skills: mcp-configure, sdk-install, first-flag.

Prerequisites

• npx: Available on PATH when using npx skills add to install companion skills (see Step 3).
• LaunchDarkly account (deferred -- inferred, not asked upfront): Do NOT ask whether the user has a LaunchDarkly account at the start. Instead, let the workflow reveal account status naturally:
  • Steps 0-3 (log, explore, detect, install skills) do not require an account. Run them first.
  • Step 4 (MCP): Present the MCP install link. If the user completes OAuth successfully, they have an account -- confirmed, no question needed.
  • Step 5 (SDK keys): If MCP is not configured (or the user declined it), account status becomes relevant at D7 when the user needs to provide keys. If they cannot provide keys, offer the signup link: https://app.launchdarkly.com/signup?source=agent.
  • This eliminates the upfront "Do you have an account?" question and lets the workflow itself surface whether the user needs to sign up.
• Keys and tokens (defer until needed): Collect these only when the path requires them.
  • Step 4 -- MCP: Hosted MCP uses OAuth; no API token or SDK key needed to configure it. Local npx MCP (federal/EU, etc.): API access token per mcp-configure and MCP Config Templates.
  • Step 5 -- SDK: SDK keys / client-side ID / mobile key when wiring env in Apply code changes, after the integration plan is confirmed. ldcli / REST for discovery: use ldcli login or an access token when you first run those commands, not at hello.
  • Key type must match the integration: server-side SDK -> SDK key; browser/client-side SDK -> Client-side ID; mobile -> Mobile key. Env variable names and bundler rules: Apply code changes.

MCP (preferred): Complete Step 4 via mcp-configure/SKILL.md before SDK work when possible. If MCP is unavailable or the user opts out, use ldcli / REST fallbacks described in that skill (including MCP Config Templates for local npx fallback when hosted MCP does not apply) -- onboarding must still be completable.