-
Notifications
You must be signed in to change notification settings - Fork 0
feat: add SDK onboarding skill for AI-agent-driven LaunchDarkly integration #25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
c58cde1
66e9b4e
147f673
ee93769
c719ee7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,37 @@ | ||
| # LaunchDarkly SDK Onboarding | ||
|
|
||
| Onboard a project to LaunchDarkly by detecting the tech stack, installing the correct SDK, initializing it, validating the connection, and creating a first feature flag. | ||
|
|
||
| ## When to Use | ||
|
|
||
| Use this skill when a user wants to: | ||
| - Add LaunchDarkly to their project | ||
| - Integrate a LaunchDarkly SDK | ||
| - Says "onboard me" or "set up LaunchDarkly" | ||
| - Get started with feature flags in an existing codebase | ||
|
|
||
| ## Workflow | ||
|
|
||
| 1. **Detect** — Identify language, framework, package manager, and existing SDK usage | ||
| 2. **Plan** — Choose the correct SDK and generate a minimal integration plan | ||
| 3. **Apply** — Install the SDK dependency and add initialization code | ||
| 4. **Run** — Start the application and confirm SDK initialization | ||
| 5. **Validate** — Verify LaunchDarkly sees the SDK connection | ||
| 6. **First Flag** — Create a feature flag, evaluate it, and toggle it | ||
| 7. **Recover** — If any step fails, diagnose and resume | ||
|
|
||
| ## Supported SDKs | ||
|
|
||
| ### Server-Side | ||
| Node.js, Python, Go, Java, Ruby, .NET, PHP, Rust, Erlang/Elixir | ||
|
|
||
| ### Client-Side | ||
| React, Vue, JavaScript (browser), Node.js (Electron) | ||
|
|
||
| ### Mobile | ||
| Swift/iOS, Android, Flutter, React Native | ||
|
|
||
| ## Requirements | ||
|
|
||
| - LaunchDarkly account with an API access token | ||
| - LaunchDarkly MCP server (optional, enhances flag creation and validation) |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,174 @@ | ||
| --- | ||
| name: launchdarkly-sdk-onboarding | ||
| description: "Onboard a project to LaunchDarkly by detecting the tech stack, installing the right SDK, initializing it, validating the connection, and creating a first feature flag. Use when the user wants to add LaunchDarkly to their project, integrate an SDK, or says 'onboard me'." | ||
| license: Apache-2.0 | ||
| compatibility: Requires LaunchDarkly API access token. Optionally uses the LaunchDarkly MCP server for flag creation and validation. | ||
| metadata: | ||
| author: launchdarkly | ||
| version: "0.1.0" | ||
| --- | ||
|
|
||
| # LaunchDarkly SDK Onboarding | ||
|
|
||
| You're using a skill that will guide you through adding LaunchDarkly to a project. Your job is to detect the tech stack, choose the right SDK, install and initialize it, validate the connection, and help the user create their first feature flag. | ||
|
|
||
| ## Account and Credentials | ||
|
|
||
| Before starting the SDK integration, ensure the user has access to LaunchDarkly: | ||
|
|
||
| 1. **Check for existing credentials**: Ask the user if they have a LaunchDarkly access token or SDK key. | ||
| 2. **If the user has an account**: Use the LaunchDarkly API (`GET /api/v2/projects/PROJECT_KEY`) or `ldcli` to retrieve the project, environment, and SDK key automatically. Ask the user for permission before reading the SDK key. | ||
| 3. **If the user does NOT have an account**: Prompt them to sign up at https://launchdarkly.com or log in via `ldcli login`. Guide them through creating their first project and environment if needed. | ||
| 4. **SDK key types**: The project response will contain the keys you need. Use the correct key type for the SDK: | ||
| - **SDK Key** for server-side SDKs | ||
| - **Client-side ID** for client-side/browser SDKs | ||
| - **Mobile Key** for mobile SDKs | ||
|
|
||
| ## Core Principles | ||
|
|
||
| 1. **Detect, don't guess**: Always inspect the repo to determine the language, framework, and package manager. Never assume. | ||
| 2. **Minimal changes**: Add SDK code alongside existing code. Don't restructure or refactor the user's project. | ||
| 3. **Match existing patterns**: If the project already has conventions (env vars, config files, initialization patterns), follow them. | ||
| 4. **Validate end-to-end**: Don't stop at installation. Confirm the SDK is actually connected to LaunchDarkly. | ||
|
|
||
| ## Workflow | ||
|
|
||
| Follow these steps in order. If any step fails, go to [Step 10: Recover](#step-10-recover). | ||
|
|
||
| ### Step 1: Detect Repository Stack | ||
|
|
||
| Before doing anything, understand the project. | ||
|
|
||
| 1. Inspect the repo for language, framework, and package manager | ||
| 2. Check for existing LaunchDarkly SDK usage | ||
| 3. Identify the application entrypoint | ||
|
|
||
| See [Detect Repository Stack](references/1.0-detect.md) for detailed instructions. | ||
|
|
||
| ### Step 2: Generate Integration Plan | ||
|
|
||
| Based on what you found, choose the correct SDK and plan the integration. | ||
|
|
||
| 1. Match the detected stack to an SDK using the [SDK Recipes](references/sdk-recipes.md) | ||
| 2. Identify which files need to change | ||
| 3. Determine if this is a server-side, client-side, or mobile integration | ||
|
|
||
| See [Generate Integration Plan](references/1.1-plan.md) for detailed instructions. | ||
|
|
||
| ### Step 3: Install Dependencies and Apply Code | ||
|
|
||
| Install the SDK and add initialization code to the project. | ||
|
|
||
| 1. Install the SDK package using the project's package manager | ||
| 2. Add SDK initialization code to the application entrypoint | ||
| 3. Configure the SDK key via environment variables | ||
|
|
||
| See [Apply Code Changes](references/1.2-apply.md) for detailed instructions. | ||
|
|
||
| ### Step 4: Start the Application | ||
|
|
||
| Verify the application runs with the SDK integrated. | ||
|
|
||
| 1. Start the application using its standard run command | ||
| 2. Confirm there are no import or initialization errors | ||
| 3. Look for SDK initialization success in logs | ||
|
|
||
| See [Start the Application](references/1.3-run.md) for detailed instructions. | ||
|
|
||
| ### Step 5: Validate SDK Connection | ||
|
|
||
| Confirm that LaunchDarkly sees the SDK connection. | ||
|
|
||
| 1. Check the SDK is active using the LaunchDarkly API or MCP | ||
| 2. Verify the connection in the LaunchDarkly dashboard | ||
|
|
||
| See [Validate SDK Connection](references/1.4-validate.md) for detailed instructions. | ||
|
|
||
| ### Step 6: Create Your First Feature Flag | ||
|
|
||
| Help the user create and evaluate a feature flag. | ||
|
|
||
| 1. Create a boolean feature flag | ||
| 2. Add flag evaluation code to the project | ||
| 3. Toggle the flag and observe the change | ||
|
|
||
| See [Create First Feature Flag](references/1.5-first-flag.md) for detailed instructions. | ||
|
|
||
| ### Step 7: Offer MCP Server Installation | ||
|
|
||
| After the SDK is working and the first flag is toggled, check if the LaunchDarkly MCP server is installed in the user's environment. | ||
|
|
||
| 1. Check if `@launchdarkly/mcp-server` is configured in the user's MCP settings | ||
| 2. If not installed, ask the user if they want to set it up | ||
| 3. If yes, guide them through installation and configuration | ||
|
|
||
| The MCP server enables richer agent-driven workflows like flag management, targeting rules, and experimentation — all without leaving the editor. | ||
|
|
||
| See [MCP Server Setup](references/1.7-mcp-setup.md) for detailed instructions. | ||
|
|
||
| ### Step 8: Leave Behind a Setup Summary | ||
|
|
||
| Generate a `LAUNCHDARKLY.md` document in the user's repository with: | ||
|
|
||
| 1. How LaunchDarkly was set up (SDK, package, init file, key configuration) | ||
| 2. Links to the project's flags dashboard, environments, and SDK docs | ||
| 3. Suggested next steps: percentage rollouts, targeting rules, experimentation, AI configs, guarded rollouts, observability | ||
| 4. Useful `ldcli` commands for flag management | ||
|
|
||
| This gives the user and their team a permanent reference. Ask the user for permission before committing it. | ||
|
|
||
| See [Onboarding Summary](references/1.8-summary.md) for the template and detailed instructions. | ||
|
|
||
| ### Step 9: Install Editor Rules for Flag Management | ||
|
|
||
| Leave behind editor-specific rules so the user's AI agent knows how to work with LaunchDarkly going forward. | ||
|
|
||
| 1. Detect which editor the user is using (Cursor, Claude Code, GitHub Copilot, etc.) | ||
| 2. Create the appropriate rules file with LaunchDarkly best practices and flag management skills | ||
| 3. Ask the user for permission before committing | ||
|
|
||
| The rules cover: when to use flags, how to evaluate them, SDK key safety, flag hygiene, and links to documentation. | ||
|
|
||
| See [Editor Rules and Skills](references/1.9-editor-rules.md) for editor-specific templates. | ||
|
|
||
| ### Step 10: Recover | ||
|
|
||
| If any step fails, diagnose the issue and resume. | ||
|
|
||
| 1. Identify the failed step and error | ||
| 2. Choose a recovery action | ||
| 3. Resume the workflow | ||
|
|
||
| See [Recovery Procedures](references/1.6-recover.md) for detailed instructions. | ||
|
|
||
ari-launchdarkly marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| ## Edge Cases | ||
|
|
||
| | Situation | Action | | ||
| |-----------|--------| | ||
| | SDK already installed | Skip to Step 4 (Run) or Step 5 (Validate) | | ||
| | Multiple languages in repo | Ask the user which target to integrate first (frontend vs backend vs mobile) | | ||
| | Monorepo | Identify the specific package/service to integrate and work within that subtree | | ||
| | No package manager detected | Ask the user which SDK they want to install and provide manual install instructions | | ||
| | Application won't start | Use the recover step to diagnose; don't block on run if the user confirms the app runs separately | | ||
|
|
||
| ## What NOT to Do | ||
|
|
||
| - Don't install an SDK without detecting the stack first | ||
| - Don't hardcode SDK keys in source code — always use environment variables | ||
| - Don't restructure the user's project or refactor existing code | ||
| - Don't skip validation — always confirm the SDK is connected | ||
| - Don't create flags before the SDK connection is validated | ||
|
|
||
| ## References | ||
|
|
||
| - [Detect Repository Stack](references/1.0-detect.md) — How to identify language, framework, and existing SDK usage | ||
| - [Generate Integration Plan](references/1.1-plan.md) — How to choose the right SDK and plan changes | ||
| - [Apply Code Changes](references/1.2-apply.md) — How to install dependencies and add initialization code | ||
| - [Start the Application](references/1.3-run.md) — How to run the app and confirm SDK initialization | ||
| - [Validate SDK Connection](references/1.4-validate.md) — How to verify LaunchDarkly sees the SDK | ||
| - [Create First Feature Flag](references/1.5-first-flag.md) — How to create, evaluate, and toggle a flag | ||
| - [Recovery Procedures](references/1.6-recover.md) — How to diagnose failures and resume | ||
| - [MCP Server Setup](references/1.7-mcp-setup.md) — How to install the LaunchDarkly MCP server | ||
| - [Onboarding Summary](references/1.8-summary.md) — Template for the setup reference document | ||
| - [Editor Rules and Skills](references/1.9-editor-rules.md) — Editor-specific rules for ongoing flag management | ||
| - [SDK Recipes](references/sdk-recipes.md) — Detection patterns, install commands, and init snippets for all SDKs | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Once we've successfully completed all these tasks, i'd like to create a papertrail that the user could reference on how LD was setup, with links to the documentation if necessary. So we give them the playbook on how to setup LD, where they can find their flags, and maybe even some additional next steps they can take (like creating an experiment, guarding a rollout, adding an AI config, adding observability). We should also leave behind some skills for the user that they can use to help manage their feature flags. We can start off with some basic feature-flag related skills. if the user is using claude, we should put it under claude rules, if they're using cursor, they should be put under cursorrules, etc...
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Implemented both of these in the latest commit (147f673): Step 8: Onboarding Summary (
Step 9: Editor Rules (
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,21 @@ | ||
| { | ||
| "name": "launchdarkly-sdk-onboarding", | ||
| "description": "Onboard a project to LaunchDarkly by detecting the tech stack, installing the right SDK, and validating the connection", | ||
| "version": "0.1.0", | ||
| "author": "LaunchDarkly", | ||
| "repository": "https://github.com/launchdarkly/agent-skills", | ||
| "skills": ["./"], | ||
| "tags": [ | ||
| "launchdarkly", | ||
| "onboarding", | ||
| "sdk-integration", | ||
| "feature-flags", | ||
| "getting-started", | ||
| "setup", | ||
| "mcp" | ||
| ], | ||
| "requirements": {}, | ||
| "optional": { | ||
| "mcp-servers": ["@launchdarkly/mcp-server"] | ||
| } | ||
| } |
Uh oh!
There was an error while loading. Please reload this page.