feat(release-autopilot): launchdarkly-release-plans skill for environment and flag release plans; onboarding follows it

.claude-plugin/marketplace.json

@@ -11,7 +11,7 @@
       "name": "launchdarkly",
       "description": "LaunchDarkly agent skills and MCP servers for feature flag management, AgentControl, and metrics",
       "source": ".",
-      "version": "1.0.7",
+      "version": "1.0.8",
       "author": {
         "name": "LaunchDarkly",
         "email": "support@launchdarkly.com"

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "launchdarkly",
-  "version": "1.0.7",
+  "version": "1.0.8",
   "description": "LaunchDarkly agent skills and MCP servers for feature flag management, AgentControl, and metrics",
   "author": {
     "name": "LaunchDarkly",
@@ -39,6 +39,7 @@
     "./skills/release-autopilot/launchdarkly-release-autopilot-settings",
     "./skills/release-autopilot/launchdarkly-release-autopilot-onboarding",
     "./skills/release-autopilot/launchdarkly-automations-cleanup-settings",
-    "./skills/release-autopilot/launchdarkly-automations-archival-settings"
+    "./skills/release-autopilot/launchdarkly-automations-archival-settings",
+    "./skills/release-autopilot/launchdarkly-release-plans"
   ]
 }

.cursor-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "launchdarkly",
-  "version": "1.0.8",
+  "version": "1.0.9",
   "description": "LaunchDarkly agent skills and mcp server for feature flag management, AgentControl, and skill authoring",
   "author": {
     "name": "LaunchDarkly",

CHANGELOG.md

@@ -4,6 +4,9 @@ All notable changes to this repository will be documented in this file.
 
 ## Unreleased
 
+- Add `release-autopilot/launchdarkly-release-plans` 1.0.0 (Claude Code plugin 1.0.8, Cursor plugin 1.0.9): one skill for both kinds of release plan. Environment release plans: read, choose (the environment's default first, other complete plans as alternatives), create from starter plans (Progressive, guarded with rollback metrics whose `analysisUnits` match the unit, at most 50% per step, or Custom) after checking the randomization unit with `search-contexts`, set the default, and edit through the MCP tools; delete, and clear the default, through the REST API. Flag release plans: list, get, create, update in place, make default, and delete, and start a flag's release from one, through the REST API (`/api/v2/projects/{projectKey}/flag-release-plans`, `/flag-release-plans/{planKey}`, `/flags/{flagKey}/flag-releases`). An environment with no complete release plan gets one first (or is left out when the user declines), and the skill never invents or points at an incomplete plan. A flag release plan stores each environment's release plan key, so a later change to that environment's default does not update it. For each REST operation the skill shows the exact curl command (with `LD-API-Version: beta`), the user runs it in their own terminal with their own API access token and pastes the output back, and the skill reads that output to continue; the agent never runs a REST command or uses a token, and never asks for a token in the chat. The commands use curl because the MCP server has no flag release plan tools and `ldcli` 3.16.0 has no command for these endpoints. Before any create, the skill checks for an existing default (environment or project), names it with a short summary, and asks whether to use it, replace it, or create another; it also names incomplete plans. Modes: Apply (confirm every write), Read-only, and Record only for skills that confirm and write later. Starter plan definitions and the custom plan questions move here from onboarding's `references/release-plans.md`.
+- `release-autopilot/launchdarkly-release-autopilot-onboarding` 1.1.0: release setup follows `launchdarkly-release-plans` in Record only mode for environment release plans and the project's flag release plan; onboarding keeps the wizard steps, the confirmation, the write order, and verification, and its own `references/release-plans.md` is gone. The flag release plan is a new "Default release" plan when the project has no default, no change when the default matches, or the default updated in place ("Update <name>" recommended, or "Keep <name>"; never a second plan). Step 7 shows what an update changes and notes that the plan keeps its release plan keys when an environment's default changes later. Step 8 writes it after the environment release plans and their defaults and before the repo writes, and Step 9 reads it back. The flag release plan is a step the user runs after "Looks good", like the browser steps: the agent shows the command, waits for the pasted output, and verifies from it. If the user skips it or it fails, it is a follow-up, auto-releasing stays on as picked, and the summary says Release Autopilot proposes no release on pull requests until the plan exists. A starter offer can be declined ("Not now"). Evals: a scripted `{ command, text }` answer stands for output the user pastes after running a shown command, and the provider's `scrub_ld_credentials` option removes LaunchDarkly credentials from the agent's shell, so cases check that the agent shows each command with the beta header, never runs one or reads a token, and reads the pasted output; the starter, guarded, no-contexts, and custom plan cases move to the new skill's suite, and onboarding adds flag release plan cases (with a shell, skipped as a follow-up with auto-releasing on, Preview, and an in-place update).
+- `release-autopilot/launchdarkly-release-autopilot-settings` 1.6.0-experimental: points to `launchdarkly-release-plans` for release plans, says Release Autopilot's pull request release proposals use only the project's flag release plans, and its description no longer says "review release policies".
 - `observability/investigate` 0.4.0: uses the response fields from launchdarkly/mcp#508, each with a fallback for servers that predate it. `get-changes` versions carry `error_spans` and `error_span_rate`, so a failing build can be quoted without a follow-up breakdown; its truncation keeps version and alert rows first; flag changes less than 10 minutes apart on one flag and environment are one row. `search-aggregations` series line up with `bucket_starts`, and `Min`/`Max` of `timestamp` are ISO 8601 UTC times, not Unix seconds. Step 1 adds a spread check: group the failing signal by `service_name` across the whole service family and cluster its error logs before narrowing to the busiest service, and step 6 reports that reach.
 - Add `observability/observability-plugin-setup` 0.1.0: turns on LaunchDarkly observability for an app that already uses a LaunchDarkly SDK. When an observability tool reports a project has never received data (`observability_set_up` / `observabilitySetUp` false, from launchdarkly/mcp#501), or the user asks for observability or session replay, the skill explains the change and asks first. It then adds the observability plugin to the app's existing client (same key, strict session replay privacy, no extra options), opens a pull request on a new branch, and confirms data arrives with `find-o11y-project` and `get-keys`. Its own `references/plugin-wiring.md` mirrors the onboarding observability-plugin table so the hosted MCP can embed it. The README gains an Observability section. Not added to the Claude Code or Cursor plugins, matching the other observability skills, which reach agents through the hosted MCP.
 - `release-autopilot/launchdarkly-release-autopilot-onboarding` 1.0.0: sets up auto-releasing with environment release plans (renamed tools) with no release policies path, and offers a progressive starter plan (production: 10% → 25% → 50%; other environments: 10% → 50%; guarded when a metric with a matching `analysisUnits` entry exists) set as each environment's default, after checking the randomization unit against stored contexts (a project with no stored contexts uses `user`). When the GitHub App install cannot be read (`reposError`) twice, setup pauses before repo mapping, and Preview lists the mapping for later with no "Connect GitHub" item. Only a `user` unit gets rollback metrics, because no read shows whether another context kind is available for guarded rollouts. Production is the environment marked critical, or the user says which. When the release plans read fails, release setup stops for that project with auto-releasing off, and for the 403 `Plan does not allow this operation` the user is told to contact LaunchDarkly support. A release plan tool missing from the server skips release setup with an update-or-reconnect message, and the rest of setup continues. Sets auto-cleanup through the MCP after confirmation, and checks auto-archival before the browser step to turn it on. Verification says GitHub is connected only without `githubConnectUrl` or `reposError`, counts archival as verified when the archival read shows it on, and lists each configured repo, default plan, and cleanup and archival setting, then offers a test pull request, the MCP and CLI, and local-agent flagging skills. A new default says which default it replaces. Evals mock the per-project cleanup and archival settings and default release plans, reject plan steps over 50% with metrics (99% without), and add starter-plan, existing-plan, running-cleanup, archival-already-on, guarded-starter, failed plan read, release plans 403 (no policy reads), missing plan tools, replaced-default, unreadable-install (setup and Preview), and no-stored-contexts cases.

README.md

@@ -31,6 +31,7 @@ Agent Skills are modular, text-based playbooks that teach an agent how to perfor
 | `release-autopilot/launchdarkly-release-autopilot-onboarding` | Step-by-step setup: pick capabilities, connect the GitHub App, map repos, choose inference, review release setup |
 | `release-autopilot/launchdarkly-release-autopilot-settings` | Turn on GitHub App auto-flagging / auto-releasing, map `owner/name` repos, or diagnose why a PR was not classified (confirm before every write) |
 | `release-autopilot/launchdarkly-automations-cleanup-settings` | Read or change a project's auto-cleanup schedule, repositories, and limits, or explain why cleanup did not open a PR (confirm before every write) |
+| `release-autopilot/launchdarkly-release-plans` | List, create, edit, make default, or delete environment release plans (with starter plans) and flag release plans, and start a flag's release from a plan (confirm before every write) |
 | `release-autopilot/launchdarkly-automations-archival-settings` | Read or change a project's auto-archival grace period, approvals, and limits, or turn it off; a person turns it on (confirm before every write) |
 
 ### AgentControl

evals/README.md

@@ -37,6 +37,7 @@ npm run eval:onboarding              # onboarding
 npm run eval:experiment-setup        # experiments/launchdarkly-experiment-setup
 npm run eval:experiment-orchestration # aws-devops-agent/experiment-orchestration
 npm run eval:release-autopilot-onboarding  # release-autopilot/launchdarkly-release-autopilot-onboarding
+npm run eval:release-plans            # release-autopilot/launchdarkly-release-plans
 
 # Quick smoke check — first test case only (~15-20s, ~$0.05)
 npm run eval:configs-create:single
@@ -48,6 +49,7 @@ npm run eval:onboarding:single
 npm run eval:experiment-setup:single
 npm run eval:experiment-orchestration:single
 npm run eval:release-autopilot-onboarding:single
+npm run eval:release-plans:single
 
 # Aggregate and CI operations
 npm run eval:all                     # Run every suite and rebuild ../eval-scores.json
@@ -126,6 +128,7 @@ evals/
      "terminated": null
    }
    ```
+   With `scrub_ld_credentials: true`, the provider removes LaunchDarkly credential variables (`LD_ACCESS_TOKEN`, `LD_BASE_URI`, `LD_API_KEY`, `LAUNCHDARKLY_*`) from the agent's environment, so a suite with builtins on can check that the agent never uses a token. A scripted answer can also be `{ command: "<regex on METHOD /api/v2/...>", text: "..." }`, which stands for output the user pasted after running a command the agent showed. In match mode it answers only the "Run this command" step, only when no option answer fits, and only when the last command shown matches.
 5. `shared/transform.js` parses the JSON before assertions run. Every assertion receives `output` as an object — **do not call `JSON.parse(output)` inside assertions**.
 
 ### Shared defaults (`shared/defaults.yaml`)