---
name: feature-flag-rollout-plan
description: "Maps the stages, audiences, metrics and kill switch for releasing a feature behind a flag, so a bad rollout is spotted fast and reversed in minutes. Use when a feature is about to ship behind a flag and the team needs staged audiences, go or stop thresholds and a tested kill switch. Do not use for choosing which feature to build or setting up the flag tooling. Related topics: product, devops."
---

# Feature Flag Rollout Plan

Maps the stages, audiences, metrics and kill switch for releasing a feature behind a flag, so a bad rollout is spotted fast and reversed in minutes.

## When to use

Use this skill when a feature is about to ship behind a flag and the team needs staged audiences, go or stop thresholds and a tested kill switch. Do not use it for choosing which feature to build or setting up the flag tooling.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Pick stage sizes and audiences that match the risk and the user base so each stage yields readable data.
3. Set go, hold and stop thresholds for the success metric and every guardrail at each stage.
4. Define the kill switch: who flips it, how fast it takes effect and what happens to data already written.
5. Write the first-hour monitoring checklist for each stage with the exact dashboards or queries to open.
6. Set a flag removal date and the owner who deletes the dead code path.

## Inputs

- **Feature** (longer free text)
- **Flag system** (free text, e.g. "LaunchDarkly or Firebase Remote Config or homegrown")
- **Risk if it goes wrong** (choose one: Cosmetic, Lost conversions, Data corruption, Outage)
- **User base size** (free text, e.g. "About 20000 weekly users")
- **Success metric** (free text, e.g. "The number that proves the feature works")
- **Guardrail metrics** (longer free text)
- **Who can roll back** (free text, e.g. "Role or team on call")

## Output

A stage table with audience, size, soak time, metrics and exit rule, a kill switch section, a monitoring checklist per stage, and a flag cleanup date with an owner.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Feature Flag Rollout Plan

Plan the staged rollout of a feature behind a flag.

- Feature: {{Feature}}
- Flag system: {{Flag system}}
- Risk if it goes wrong: {{Risk if it goes wrong}}
- User base size: {{User base size}}
- Success metric: {{Success metric}}
- Guardrail metrics: {{Guardrail metrics}}
- Who can roll back: {{Who can roll back}}

Design the rollout in stages, each with an audience, a size, a minimum soak time and the exit rule to advance. A typical path is internal staff, a small percentage of low-risk users, a larger slice, then everyone, but fit it to the risk and the user count so each stage yields enough data to read. For every stage, state the metric thresholds that mean go, hold or stop, using the success metric and guardrails given. Define the kill switch precisely: who flips it, how long it takes to take effect, and what happens to users and data already touched, including any migration that does not reverse. Add a monitoring checklist for the first hour of each stage. Finish with a flag cleanup date, because stale flags become permanent code paths.

## Pitfalls

- Advancing on elapsed time alone, when the stage has too few users to show a regression.
- Treating the kill switch as safe without checking data written under the flag, which may not roll back.
- Leaving the flag in place after full rollout, which doubles the code paths to test forever.