diff --git a/CHANGELOG.md b/CHANGELOG.md index e68f55a3..1f69d169 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -4,6 +4,7 @@ All notable changes to this repository will be documented in this file. ## Unreleased +- `onboarding/mcp-configure` 0.1.1: Claude Code loads MCP servers only at session start, so a server added mid-session needs the user to quit, resume with `claude --continue`, and authenticate from `/mcp`. The skill no longer says Claude Code needs no restart or that its OAuth prompt appears on the first tool call. - `experiments/launchdarkly-experiment-setup`: require the flag and variations, hypothesis, and primary metric from the user before creating anything; if the named flag does not exist, offer three choices in one message: correct the key, listing similar flags; create it themselves and then continue; or have the agent create it. For the last, propose the key, name, type, and variations, say it will be created off, follow `launchdarkly-flag-create` when that skill is installed, and wait for an explicit yes before `create-flag`. Never create a flag unless they pick that option and approve the details; add flag variations only when the user explicitly asks, and otherwise say which variations exist and ask; suggest a control from what the flag serves today, or the off variation when it is off, and ask instead when the flag is brand new (created in this conversation, or status `new`: created fewer than seven days ago and never evaluated), the targeted rule is a percentage rollout, or the flag is off and that environment is `inactive` (no one is currently being served the off variation); suggest `user` as the randomization unit only when `search-contexts` confirms it is the only context kind in use, and otherwise ask; label every suggestion with a one-line reason and let the user change it before approval; before showing a design, gather every missing piece in one message, and skip that message when nothing is missing; include a new metric's kind, basis, and measure when the user's wording has not already made them clear; show the design only when nothing is blank, then stop until the user approves it; create the metric and experiment only after the user approves a complete design they have seen; if they change anything after seeing it, show the updated design and ask once more; call `list-metric-events` only after a missing primary metric is known to be a custom event and the user has named its event key; if that event is not reaching LaunchDarkly, warn in the design, list at most 10 arriving custom event keys (preferring ones similar to the key the user gave), and let the user correct the key or approve as is; create the metric and experiment on approval even if it has not arrived; right before starting, call `list-metric-events` again for a custom-event primary metric and, if it is still not arriving, ask whether to start anyway, in the same message as the flag-off question when both apply. A metric name alone is not that key. Do not skip the flow check or block creation before the event is identified; start an iteration only after the user says to start. Omit `methodology` unless the user chooses one; the design shows statistics as LaunchDarkly default (frequentist, sequential testing) unless they chose otherwise, and a Bayesian choice is sent as `methodology` `"bayesian"`. When stopping, report significance for a frequentist experiment and probability to beat baseline or probability to be best for a Bayesian one (0.3.0). - `onboarding` 0.4.0: add `references/sdk/observability-plugin.md` and load it from the SDK install when the user asks for observability, session replay, error monitoring, logs, or tracing. Covers browser (React, JavaScript, Vue), Next.js, Node.js, React Native, Python, Ruby, Go, .NET, iOS, and Android. The plugin goes on the existing client's `plugins` option and reuses its key. `recipes.md` points to the new reference instead of its per-SDK one-liners. The request is honored at any point, including a follow-up after onboarding finished; session replay defaults to strict privacy; an SDK too old for `plugins` gets a question before any major upgrade. Adds three onboarding evals for these paths. - Claude Code marketplace: add `version`, `author`, `homepage`, `repository`, `license`, `category`, and `keywords` to the `launchdarkly` entry in `.claude-plugin/marketplace.json` so directory listings get the same metadata as `.claude-plugin/plugin.json`. A test keeps the two in sync. diff --git a/skills.json b/skills.json index b09431de..acfae194 100644 --- a/skills.json +++ b/skills.json @@ -447,7 +447,7 @@ "name": "mcp-configure", "description": "Configure the LaunchDarkly hosted MCP server during onboarding. Use when the parent LaunchDarkly onboarding skill reaches the MCP offer, after the first flag works. Supports Cursor, Claude Code, Windsurf, GitHub Copilot, and other MCP-compatible agents. OAuth authentication; no API keys for the hosted server.", "path": "skills/onboarding/mcp-configure", - "version": "0.1.0", + "version": "0.1.1", "license": "Apache-2.0", "compatibility": "Requires an MCP-compatible coding agent and a LaunchDarkly account" }, diff --git a/skills/onboarding/mcp-configure/SKILL.md b/skills/onboarding/mcp-configure/SKILL.md index cb113919..0959f350 100644 --- a/skills/onboarding/mcp-configure/SKILL.md +++ b/skills/onboarding/mcp-configure/SKILL.md @@ -5,7 +5,7 @@ license: Apache-2.0 compatibility: Requires an MCP-compatible coding agent and a LaunchDarkly account metadata: author: launchdarkly - version: "0.1.0" + version: "0.1.1" --- # LaunchDarkly MCP Server Configuration (onboarding) @@ -80,17 +80,17 @@ After writing the config, some agents need extra steps. **Do not** send users th **Claude Code:** -- Authorization happens automatically on first MCP tool call via OAuth prompt. File-based setup: [Claude Code MCP doc](https://docs.claude.com/en/docs/claude-code/mcp). +- Claude Code loads MCP servers only when a session starts, so a server added mid-session is not available yet. The user quits, resumes the session with `claude --continue`, then runs `/mcp`, selects the LaunchDarkly server, and authenticates. File-based setup: [Claude Code MCP doc](https://docs.claude.com/en/docs/claude-code/mcp). **GitHub Copilot:** - Click **Save** after adding the MCP configuration in repo settings. Use the [GitHub Copilot MCP doc](https://docs.github.com/en/copilot/customizing-copilot/extending-copilot-coding-agent-with-mcp) for the exact **Settings** path on github.com. -### Step 5: Verify MCP Tools (No Mandatory Restart) +### Step 5: Verify MCP Tools -Restart is no longer required for Cursor or Claude Code after enabling an MCP server. Probe for tools immediately after the user confirms they've enabled and authorized the server. +Cursor does not need a restart after enabling an MCP server. Claude Code does: it loads MCP servers only at session start (see Step 4). Probe for tools immediately after the user confirms they've enabled and authorized the server. -1. **Tell the user to enable and authorize the server.** In Cursor: toggle on the LaunchDarkly server in MCP settings and click **Connect**. In Claude Code: the OAuth prompt appears on first tool call. Do **not** tell them to restart yet. +1. **Tell the user to enable and authorize the server.** In Cursor: toggle on the LaunchDarkly server in MCP settings and click **Connect**. In Claude Code: quit, resume with `claude --continue`, then authenticate the server from `/mcp`. Do **not** tell Cursor users to restart yet. 2. **Probe immediately.** After the user confirms the server is enabled, call a lightweight MCP tool (e.g. `list-feature-flags` with the user's project key). Do not ask the user whether MCP is working — just try it. - **Success** (normal response, even an empty flag list): MCP is live. Continue. @@ -98,7 +98,7 @@ Restart is no longer required for Cursor or Claude Code after enabling an MCP se - **Tool not found or timeout** (tool not recognized, connection refused, no response): the editor hasn't picked up the server yet. Go to step 3b. 3a. **Auth failure path.** The MCP server is reachable but OAuth is incomplete or expired — restarting the editor won't help. - - Tell the user: "The MCP server responded but authorization failed. In Cursor: open MCP settings, find the LaunchDarkly server, and click **Connect** to re-authorize. In Claude Code: the next MCP tool call should re-trigger the OAuth prompt." + - Tell the user: "The MCP server responded but authorization failed. In Cursor: open MCP settings, find the LaunchDarkly server, and click **Connect** to re-authorize. In Claude Code: run `/mcp`, select the LaunchDarkly server, and authenticate." - Use [MCP UI links](references/mcp-ui-links.md) to give the user a direct shortcut to their agent's MCP settings. - Re-probe after the user confirms they re-authorized. - If the re-probe succeeds: continue with onboarding. @@ -106,7 +106,7 @@ Restart is no longer required for Cursor or Claude Code after enabling an MCP se 3b. **Server-not-found path.** The editor likely hasn't loaded the new MCP config yet. - Tell the user: "The MCP tools aren't visible yet. Some editors need a restart to pick up new MCP servers. Restart your editor and say **'continue LaunchDarkly onboarding'** when you're back — I'll resume from here." - - Be specific about how to restart: "Restart Cursor" / "reload Claude Code" / "refresh the Copilot agent" depending on what you detected in Step 1. + - Be specific about how to restart: "Restart Cursor" / "quit Claude Code and resume with `claude --continue`" / "refresh the Copilot agent" depending on what you detected in Step 1. 4. **On resume after restart:** The parent onboarding skill detects live state, so no log file is needed. When the next turn starts: - Re-probe for MCP tools silently. @@ -147,7 +147,7 @@ Restart is no longer required for Cursor or Claude Code after enabling an MCP se - Don't configure a local npx-based server. Always use the hosted server. - Don't ask for or store API keys. The hosted server uses OAuth. - Don't auto-migrate from the deprecated `mcp/aiconfigs` — always ask via the blocking question. -- Don't suggest restart as the first step — probe for tools immediately after the user enables the server. +- Don't suggest restart as the first step in Cursor — probe for tools immediately after the user enables the server. - Don't suggest restart for auth errors (401/403) — the server was found, so a restart won't help. Guide the user to re-authorize instead. ## References