/onboardingv2

Onboarding Summary

After completing the onboarding flow, leave behind a summary document in the user's repository so they (and their team) have a reference for how LaunchDarkly was set up and what to do next.

Step 1: Generate the Summary Document

Create a file called LAUNCHDARKLY.md (or docs/LAUNCHDARKLY.md if the project has a docs/ directory) in the user's repository with the following sections. Fill in the details based on what was done during onboarding. Collect the LaunchDarkly project key and environment key ({PROJECT_KEY} / {ENV_KEY}) from the same place you used during onboarding (dashboard URLs, MCP tools, or Project settings → Environments) if they were not written into the plan explicitly.

Template

The wrapper below uses ~~~markdown so a nested ```json block inside the template does not break Markdown rendering. (The generated LAUNCHDARKLY.md file itself may use normal ``` fences.)

# LaunchDarkly Setup

This project uses [LaunchDarkly](https://launchdarkly.com) for feature flag management.

## SDK Details

- **SDK**: {SDK_NAME} ({SDK_PACKAGE})
- **SDK Type**: {server-side | client-side | mobile | edge}
- **Key Type**: {SDK Key | Client-side ID | Mobile Key}
- **Installed via**: {INSTALL_COMMAND}
- **Initialization file**: {ENTRYPOINT_FILE}

## Configuration

The SDK key is configured via the `{ENV_VAR_NAME}` environment variable.

- **Do not hardcode** the SDK key in source code.
- Add the key to your `.env` file locally (already in `.gitignore`).
- For production, set it in your deployment environment (e.g., CI/CD secrets, container env vars, cloud config).

## Where to Find Things

| What | Where |
|------|-------|
| Feature flags dashboard | https://app.launchdarkly.com/projects/{PROJECT_KEY}/flags |
| Project settings | https://app.launchdarkly.com/settings/projects/{PROJECT_KEY} |
| Environments | https://app.launchdarkly.com/settings/projects/{PROJECT_KEY}/environments |
| API access tokens | https://app.launchdarkly.com/settings/authorization |
| SDK documentation | {SDK_DOCS_URL} |
| LaunchDarkly docs | https://launchdarkly.com/docs |

## How Feature Flags Work in This Project

1. Flags are evaluated using the LaunchDarkly SDK in `{ENTRYPOINT_FILE}`
2. Flag values are fetched from LaunchDarkly based on the evaluation context (user/device/org)
3. Changes to flags in the dashboard take effect immediately (server-side SDKs use streaming by default)

### Example: Evaluating a Flag

{INSERT_LANGUAGE_SPECIFIC_EXAMPLE}

## Next Steps

Here are some things you can do now that LaunchDarkly is set up:

### Feature Flag Best Practices
- **Use flags for every new feature**: Wrap new features in flags so you can release and roll back independently of deployments.
- **Clean up temporary flags**: Mark flags as temporary during creation and archive them when no longer needed.
- **Use descriptive flag keys**: e.g., `enable-checkout-v2` instead of `flag-1`.

### Advanced Capabilities
- **[Percentage Rollouts](https://launchdarkly.com/docs/home/targeting-flags/rollouts)** — Gradually roll out features to a percentage of users.
- **[Targeting Rules](https://launchdarkly.com/docs/home/targeting-flags/targeting-rules)** — Target specific users, segments, or contexts.
- **[Experimentation](https://launchdarkly.com/docs/home/about-experimentation)** — Run A/B tests and measure the impact of flag variations.
- **[AI Configs](https://launchdarkly.com/docs/home/ai-configs)** — Manage AI model configurations and prompts with feature flags.
- **[Guarded Rollouts](https://launchdarkly.com/docs/home/guarded-rollouts)** — Automatically roll back flag changes based on metric guardrails.
- **[Observability](https://launchdarkly.com/docs/home/observability)** — Monitor flag evaluations and SDK performance with built-in telemetry.

### AI Agent Integration (MCP Server)

Install the [LaunchDarkly MCP server](https://github.com/launchdarkly/mcp-server) to let your AI agent manage feature flags directly from your editor. With it, your agent can:

- **Create and manage flags** — Ask your agent to create a new feature flag, and it will handle the API calls for you.
- **Toggle flags on/off** — Turn features on or off across environments without leaving your editor.
- **Set up targeting rules** — Configure percentage rollouts, user targeting, and segment-based rules through natural language.
- **Clean up stale flags** — Ask your agent to find temporary flags that are fully rolled out and ready to archive.
- **Run experiments** — Set up A/B tests and monitor results through your agent.
- **Manage AI configs** — Update model configurations and prompts managed by LaunchDarkly.

**Setup:** [Hosted MCP](https://launchdarkly.com/docs/home/getting-started/mcp-hosted) — uses OAuth; no tokens or API keys needed in config files. See the [MCP server docs](https://github.com/launchdarkly/mcp-server) for editor-specific setup instructions.

## Step 2: Fill in the Template

Replace all `{PLACEHOLDER}` values with the actual values from the onboarding session (gather any you did not write down earlier from **Project settings → Environments** in the LaunchDarkly dashboard or from MCP tools):

- `{SDK_NAME}`: The human-readable SDK name (e.g., "Node.js Server SDK")
- `{SDK_PACKAGE}`: The package name (e.g., `@launchdarkly/node-server-sdk`)
- `{INSTALL_COMMAND}`: The install command used (e.g., `npm install @launchdarkly/node-server-sdk`)
- `{ENTRYPOINT_FILE}`: The file where initialization code was added
- `{ENV_VAR_NAME}`: The environment variable name used for the SDK key (or client-side ID env name)
- `{PROJECT_KEY}`: The LaunchDarkly **project** key (used in dashboard URLs and MCP tool calls)
- `{ENV_KEY}`: The LaunchDarkly **environment** key for the environment whose SDK key / client-side ID you used (e.g., `production`, `test`, `development`) — used in dashboard URLs scoped per environment
- `{SDK_DOCS_URL}`: Link to the specific SDK documentation
- `{INSERT_LANGUAGE_SPECIFIC_EXAMPLE}`: A short code snippet showing flag evaluation in the project's language

## Step 3: Commit the Summary

Add the file to version control so the whole team can reference it:

```bash
git add LAUNCHDARKLY.md
git commit -m "docs: add LaunchDarkly setup reference"
```

Ask the user for permission before committing. If they prefer not to commit it, that's fine — they still have the file locally.