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.
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.
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.)
markdown
# LaunchDarkly SetupThis 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}## ConfigurationThe SDK key is configured via the `{ENV_VAR_NAME}`
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 LaunchDarkly or from MCP tools / ldcli):
{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 (URL segment and ldcli --project)
{ENV_KEY}: The LaunchDarkly environment key for the environment whose SDK key / client-side ID you used (e.g., production, test, development)—required for ldcli commands that take --environment and for the dashboard links that are scoped per environment where applicable
{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
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.
- **[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.
### Agent Integration (MCP Server)
Install the [LaunchDarkly MCP server](https://github.com/launchdarkly/mcp-server) to let your 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 configs** — Update model configurations and prompts managed by LaunchDarkly.
**Setup:** Use the [Hosted MCP](https://launchdarkly.com/docs/home/getting-started/mcp-hosted) server, which uses OAuth — no tokens stored in config files.
See the [MCP server docs](https://github.com/launchdarkly/mcp-server) for editor-specific setup instructions.
### Useful CLI Commands
If you have `ldcli` installed:
| Command | Description |
|---------|-------------|
| `ldcli flags list --project {PROJECT_KEY}` | List all feature flags |
| `ldcli flags toggle-on --project {PROJECT_KEY} --environment {ENV_KEY} --flag FLAG_KEY` | Turn a flag on |
| `ldcli flags create --project {PROJECT_KEY} --data '{"name": "My Flag", "key": "my-flag", "kind": "boolean"}'` | Create a new flag |
| `ldcli environments list --project {PROJECT_KEY}` | List environments and SDK keys |