Update to LaunchDarkly

{
  "name": "launchdarkly-guarded-rollout",
  "description": "Configure guarded rollouts with progressive traffic increases, metric monitoring, and automatic rollback. Use when releasing features gradually with safety thresholds.",
  "included_files": [],
  "skill_md_contents": "---\nname: launchdarkly-guarded-rollout\ndescription: \"Configure guarded rollouts with progressive traffic increases, metric monitoring, and automatic rollback. Use when releasing features gradually with safety thresholds.\"\nlicense: Apache-2.0\ncompatibility: Requires the remotely hosted LaunchDarkly MCP server\nmetadata:\n  author: launchdarkly\n  version: \"0.1.0\"\n---\n\n# LaunchDarkly Guarded Rollouts\n\nYou're using a skill that will guide you through configuring guarded rollouts in LaunchDarkly. Your job is to design rollout stages, select monitoring metrics, configure regression thresholds, and start the rollout.\n\n## Prerequisites\n\nThis skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.\n\n**Required MCP tools:**\n- `start-guarded-rollout` -- start a progressive rollout with monitoring\n- `get-flag` -- inspect the flag and its variations\n- `list-metrics` -- find metrics to monitor during the rollout\n\n**Optional MCP tools:**\n- `stop-guarded-rollout` -- halt an active rollout immediately\n- `toggle-flag` -- ensure the flag is turned on before starting\n- `create-metric` -- create metrics if they don't exist\n\n## Core Concepts\n\n### What Are Guarded Rollouts?\n\nA guarded rollout progressively increases traffic to a new feature flag variation through a series of stages. At each stage, LaunchDarkly monitors selected metrics for regressions. If a regression is detected, the rollout can automatically pause and notify the team — or even roll back.\n\n### Key Components\n\n| Component | Description |\n|-----------|-------------|\n| **Test variation** | The new variation being rolled out |\n| **Control variation** | The existing/baseline variation |\n| **Stages** | Steps with increasing traffic percentage and monitoring windows |\n| **Metrics** | What to monitor for regressions (error rate, latency, etc.) |\n| **Regression threshold** | How much a metric can degrade before triggering action |\n| **On regression** | Whether to notify, rollback, or both when a threshold is breached |\n\n### Rollout Weight Units\n\nRollout weights use thousandths (basis points):\n- `1000` = 1%\n- `10000` = 10%\n- `50000` = 50%\n- `100000` = 100%\n\n### Monitoring Window\n\nThe monitoring window is specified in milliseconds:\n- `3600000` = 1 hour\n- `86400000` = 24 hours\n- `604800000` = 7 days\n\n## Core Principles\n\n1. **Start Small**: Begin with a low percentage (1-5%) to catch issues early\n2. **Monitor What Matters**: Choose metrics that reflect user experience\n3. **Set Realistic Thresholds**: Too tight = false alarms; too loose = missed regressions\n4. **Allow Time**: Each stage needs enough monitoring time for signal to emerge\n5. **Have a Rollback Plan**: Always configure at least notification on regression\n\n## Workflow\n\n### Step 1: Prepare\n\nBefore starting a guarded rollout:\n\n1. Use `get-flag` to inspect the flag — note the variation IDs for test and control\n2. Use `list-metrics` to find metrics suitable for monitoring\n3. Ensure the flag is **on** in the target environment (use `toggle-flag` if needed)\n4. Confirm there's no active guarded rollout on this flag already\n\n### Step 2: Design Stages\n\nPlan the rollout progression. A typical pattern:\n\n| Stage | Traffic | Monitoring Window | Purpose |\n|-------|---------|-------------------|---------|\n| 1 | 1% | 1 hour | Smoke test — catch obvious crashes |\n| 2 | 10% | 24 hours | Early signal on metrics |\n| 3 | 50% | 24 hours | Confidence building |\n| 4 | 100% | 24 hours | Full rollout with monitoring |\n\n### Step 3: Configure Metrics\n\nSelect metrics that indicate problems:\n\n| Metric Type | Example | Threshold | Action |\n|-------------|---------|-----------|--------|\n| Error rate | `api-error-rate` | 0.05 (5% increase) | Rollback |\n| Latency | `p99-response-time` | 0.2 (20% increase) | Notify |\n| Conversion | `checkout-completed` | 0.1 (10% decrease) | Notify + Rollback |\n\n### Step 4: Start the Rollout\n\nUse `start-guarded-rollout`:\n\n```json\n{\n  \"projectKey\": \"my-project\",\n  \"flagKey\": \"new-checkout-flow\",\n  \"environmentKey\": \"production\",\n  \"testVariationId\": \"variation-id-for-new-flow\",\n  \"controlVariationId\": \"variation-id-for-current-flow\",\n  \"randomizationUnit\": \"user\",\n  \"stages\": [\n    {\"rolloutWeight\": 1000, \"monitoringWindowMilliseconds\": 3600000},\n    {\"rolloutWeight\": 10000, \"monitoringWindowMilliseconds\": 86400000},\n    {\"rolloutWeight\": 50000, \"monitoringWindowMilliseconds\": 86400000},\n    {\"rolloutWeight\": 100000, \"monitoringWindowMilliseconds\": 86400000}\n  ],\n  \"metrics\": [\n    {\n      \"metricKey\": \"api-error-rate\",\n      \"onRegression\": {\"notify\": true, \"rollback\": true},\n      \"regressionThreshold\": 0.05\n    },\n    {\n      \"metricKey\": \"checkout-completed\",\n      \"onRegression\": {\"notify\": true, \"rollback\": false},\n      \"regressionThreshold\": 0.1\n    }\n  ]\n}\n```\n\n### Step 5: Verify\n\n1. Use `get-flag` to confirm the guarded rollout is active\n2. Check that the flag shows the rollout configuration in the environment\n3. Monitor for any immediate regression notifications\n\n**Report results:**\n- Guarded rollout started with N stages\n- M metrics being monitored\n- First stage at X% traffic for Y hours\n\n## Stopping a Rollout\n\nIf issues arise or you need to halt the rollout:\n\n```json\n{\n  \"projectKey\": \"my-project\",\n  \"flagKey\": \"new-checkout-flow\",\n  \"environmentKey\": \"production\"\n}\n```\n\nThis immediately stops the progressive rollout and locks the flag at its current state.\n\n## Edge Cases\n\n| Situation | Action |\n|-----------|--------|\n| Flag is off | Turn it on first with `toggle-flag` — rollouts require the flag to be on |\n| Active rollout exists | Stop it first with `stop-guarded-rollout` before starting a new one |\n| No suitable metrics | Create metrics first with `create-metric` |\n| Approval required | If the environment requires approvals, the tool will return an approval URL |\n\n## What NOT to Do\n\n- Don't start a guarded rollout on a flag that's turned off\n- Don't skip the monitoring window design — rushing through stages defeats the purpose\n- Don't set regression thresholds to 0 — small fluctuations are normal\n- Don't forget to configure at least one metric — a rollout without monitoring is just a regular rollout\n"
}