OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add launchdarkly/agent-skills --skill launchdarkly-guarded-rollout
Configure guarded rollouts with progressive traffic increases, metric monitoring, and automatic rollback. Use when releasing features gradually with safety thresholds.
This repo is now called launchdarkly/ai-tooling. Both names install the same content, but the install count here only covers this one.
npx skills add launchdarkly/agent-skills --skill launchdarkly-guarded-rollout
You'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.
This skill requires the remotely hosted LaunchDarkly MCP server to be configured in your environment.
Required MCP tools:
start-guarded-rollout -- start a progressive rollout with monitoringget-flag -- inspect the flag and its variationslist-metrics -- find metrics to monitor during the rolloutOptional MCP tools:
stop-guarded-rollout -- halt an active rollout immediatelytoggle-flag -- ensure the flag is turned on before startingcreate-metric -- create metrics if they don't existA 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.
| Component | Description |
|---|---|
| Test variation | The new variation being rolled out |
| Control variation | The existing/baseline variation |
| Stages | Steps with increasing traffic percentage and monitoring windows |
| Metrics | What to monitor for regressions (error rate, latency, etc.) |
| Regression threshold | How much a metric can degrade before triggering action |
| On regression | Whether to notify, rollback, or both when a threshold is breached |
Rollout weights use thousandths (basis points):
1000 = 1%10000 = 10%50000 = 50%100000 = 100%The monitoring window is specified in milliseconds:
3600000 = 1 hour86400000 = 24 hours604800000 = 7 daysBefore starting a guarded rollout:
get-flag to inspect the flag — note the variation IDs for test and controllist-metrics to find metrics suitable for monitoringtoggle-flag if needed)Plan the rollout progression. A typical pattern:
| Stage | Traffic | Monitoring Window | Purpose |
|---|---|---|---|
| 1 | 1% | 1 hour | Smoke test — catch obvious crashes |
| 2 | 10% | 24 hours | Early signal on metrics |
| 3 | 50% | 24 hours | Confidence building |
| 4 | 100% | 24 hours | Full rollout with monitoring |
Select metrics that indicate problems:
| Metric Type | Example | Threshold | Action |
|---|---|---|---|
| Error rate | api-error-rate | 0.05 (5% increase) | Rollback |
| Latency | p99-response-time | 0.2 (20% increase) | Notify |
| Conversion | checkout-completed | 0.1 (10% decrease) | Notify + Rollback |
Use start-guarded-rollout:
get-flag to confirm the guarded rollout is activeReport results:
If issues arise or you need to halt the rollout:
This immediately stops the progressive rollout and locks the flag at its current state.
| Situation | Action |
|---|---|
| Flag is off | Turn it on first with toggle-flag — rollouts require the flag to be on |
| Active rollout exists | Stop it first with stop-guarded-rollout before starting a new one |
| No suitable metrics | Create metrics first with create-metric |
| Approval required | If the environment requires approvals, the tool will return an approval URL |
{
"projectKey": "my-project",
"flagKey": "new-checkout-flow",
"environmentKey": "production"
}