onboarding

Name: onboarding
Author: launchdarkly

77installs6forks

How to install onboarding?

launchdarkly/ai-tooling/onboarding

$npx -y skills add launchdarkly/ai-tooling --skill onboarding

Installs into the current project.

Summary

Onboard a project to LaunchDarkly: kickoff roadmap, resumable log, explore repo, MCP, companion flag skills, nested SDK install (detect/plan/apply), first flag. Use when adding LaunchDarkly, setting up or integrating feature flags in a project, SDK integration, or 'onboard me'.

Files · 1

View on GitHub

SKILL.md

1	# LaunchDarkly SDK Onboarding
2
3	Orchestrates LaunchDarkly setup in an existing codebase: on kickoff, show a roadmap in chat (see [Kickoff: onboarding roadmap](#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](mcp-configure/SKILL.md), [sdk-install](sdk-install/SKILL.md), [first-flag](first-flag/SKILL.md).
4
5	## Prerequisites
6
7	- `npx`: Available on PATH when using `npx skills add` to install companion skills (see Step 3).
8	- 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:
9	- Steps 0-3 (log, explore, detect, install skills) do not require an account. Run them first.
10	- Step 4 (MCP): Present the MCP install link. If the user completes OAuth successfully, they have an account -- confirmed, no question needed.
11	- 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 resolved signup link (see [Source Attribution](#source-attribution)).
12	- This eliminates the upfront "Do you have an account?" question and lets the workflow itself surface whether the user needs to sign up.
13	- Keys and tokens (defer until needed): Collect these only when the path requires them.
14	- Step 4 -- MCP: Hosted MCP uses OAuth; no API token or SDK key needed to configure it.
15	- Step 5 -- SDK: SDK keys / client-side ID / mobile key when wiring env in [Apply code changes](sdk-install/apply/SKILL.md), 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.
16	- 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](sdk-install/apply/SKILL.md).
17
18	MCP (preferred): Complete Step 4 via [mcp-configure/SKILL.md](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 -- onboarding must still be completable.
19
20	Optional MCP tools (when configured):
21
22	- `get-environments` -- list environments for a project; the response includes SDK keys, client-side IDs, and mobile keys per environment. Use this as the single source for all key types -- do not make separate requests for individual keys.
23	- `create-feature-flag` -- create the boolean flag for [Step 6: Create Your First Feature Flag](#step-6-create-your-first-feature-flag).
24	- `update-feature-flag` -- toggle or patch flag configuration during Step 6; see [Create first feature flag](first-flag/SKILL.md) for ldcli/API fallbacks.
25
26	Other MCP tools you may use if present (not required): `list-feature-flags`, `get-feature-flag`, `get-flag-status-across-environments`.
27
28	## Agent Behavior Directives
29
30	### Source Attribution
31
32	The signup URL used throughout onboarding includes a `source` query parameter for attribution. The default value is `agent`, producing `https://app.launchdarkly.com/signup?source=agent`. However, the source is dynamic based on the user's original prompt:
33
34	- If the user's initial message (the prompt that triggered onboarding) contains the marker `source-launchdarkly`, set the source to `ldwebsite` → `https://app.launchdarkly.com/signup?source=ldwebsite`.
35	- Otherwise, keep the default source `agent` → `https://app.launchdarkly.com/signup?source=agent`.
36
37	Detect this once at kickoff (before Step 0) by scanning the user's original message for the substring `source-launchdarkly`. Store the resolved signup URL for the session and use it wherever this skill or any nested skill directs the user to sign up. The marker is metadata for the agent — do not echo it back to the user or include it in any user-facing output.
38
39	### Progress Tracking
40
41	The

People who liked this also viewed

6 picks

Type

onboarding

77installs6forks

View on GitHub

How to install onboarding?

launchdarkly/ai-tooling/onboarding

$npx -y skills add launchdarkly/ai-tooling --skill onboarding

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# LaunchDarkly SDK Onboarding
2
3	Orchestrates LaunchDarkly setup in an existing codebase: on kickoff, show a roadmap in chat (see [Kickoff: onboarding roadmap](#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](mcp-configure/SKILL.md), [sdk-install](sdk-install/SKILL.md), [first-flag](first-flag/SKILL.md).
4
5	## Prerequisites
6
7	- `npx`: Available on PATH when using `npx skills add` to install companion skills (see Step 3).
8	- 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:
9	- Steps 0-3 (log, explore, detect, install skills) do not require an account. Run them first.
10	- Step 4 (MCP): Present the MCP install link. If the user completes OAuth successfully, they have an account -- confirmed, no question needed.
11	- 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 resolved signup link (see [Source Attribution](#source-attribution)).
12	- This eliminates the upfront "Do you have an account?" question and lets the workflow itself surface whether the user needs to sign up.
13	- Keys and tokens (defer until needed): Collect these only when the path requires them.
14	- Step 4 -- MCP: Hosted MCP uses OAuth; no API token or SDK key needed to configure it.
15	- Step 5 -- SDK: SDK keys / client-side ID / mobile key when wiring env in [Apply code changes](sdk-install/apply/SKILL.md), 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.
16	- 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](sdk-install/apply/SKILL.md).
17
18	MCP (preferred): Complete Step 4 via [mcp-configure/SKILL.md](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 -- onboarding must still be completable.
19
20	Optional MCP tools (when configured):
21
22	- `get-environments` -- list environments for a project; the response includes SDK keys, client-side IDs, and mobile keys per environment. Use this as the single source for all key types -- do not make separate requests for individual keys.
23	- `create-feature-flag` -- create the boolean flag for [Step 6: Create Your First Feature Flag](#step-6-create-your-first-feature-flag).
24	- `update-feature-flag` -- toggle or patch flag configuration during Step 6; see [Create first feature flag](first-flag/SKILL.md) for ldcli/API fallbacks.
25
26	Other MCP tools you may use if present (not required): `list-feature-flags`, `get-feature-flag`, `get-flag-status-across-environments`.
27
28	## Agent Behavior Directives
29
30	### Source Attribution
31
32	The signup URL used throughout onboarding includes a `source` query parameter for attribution. The default value is `agent`, producing `https://app.launchdarkly.com/signup?source=agent`. However, the source is dynamic based on the user's original prompt:
33
34	- If the user's initial message (the prompt that triggered onboarding) contains the marker `source-launchdarkly`, set the source to `ldwebsite` → `https://app.launchdarkly.com/signup?source=ldwebsite`.
35	- Otherwise, keep the default source `agent` → `https://app.launchdarkly.com/signup?source=agent`.
36
37	Detect this once at kickoff (before Step 0) by scanning the user's original message for the substring `source-launchdarkly`. Store the resolved signup URL for the session and use it wherever this skill or any nested skill directs the user to sign up. The marker is metadata for the agent — do not echo it back to the user or include it in any user-facing output.
38
39	### Progress Tracking
40
41	The

People who liked this also viewed

6 picks

Type