Designs feature-flag systems and lifecycle policy – flag taxonomy (release, ops/kill-switch, experiment, permission), percentage rollouts with stable bucketing, safe defaults, and mandatory removal deadlines so flags don't rot into dead code.
Designs feature-flag systems and lifecycle policy - flag taxonomy (release, ops/kill-switch, experiment, permission), percentage rollouts with stable bucketing, safe defaults, and mandatory removal deadlines so flags don't rot into dead code. Use when someone asks "how should I roll this out behind a flag", "kill switch vs feature flag", "how do I do a percentage rollout", "we have hundreds of stale flags", or is wiring up LaunchDarkly or a homegrown flag service. Do NOT use for designing the A/B test analysis itself - use ab-test-analyzer instead - and do NOT use for CI/CD pipeline gating - use github-actions instead.This is the skill's description: the text your AI reads to decide when the skill applies.
feature-flags/SKILL.md
---
name: Feature Flags
description: Designs feature-flag systems and lifecycle policy - flag taxonomy (release, ops/kill-switch, experiment, permission), percentage rollouts with stable bucketing, safe defaults, and mandatory removal deadlines so flags don't rot into dead code. Use when someone asks "how should I roll this out behind a flag", "kill switch vs feature flag", "how do I do a percentage rollout", "we have hundreds of stale flags", or is wiring up LaunchDarkly or a homegrown flag service. Do NOT use for designing the A/B test analysis itself - use ab-test-analyzer instead - and do NOT use for CI/CD pipeline gating - use github-actions instead.
---
# Feature Flags
Flags decouple deploy from release: code ships dark and turns on safely, in stages, with an instant off switch. The costly mistake this skill prevents is flag debt - every flag is a fork in your codebase that doubles the test matrix, and a flag without an owner and a removal deadline set at creation becomes permanent dead code that someone flips three years later during an incident with no idea what it does.
## Operating procedure
### Step 1: Gather inputs
Before creating any flag, collect:
1. Purpose - which of the four types below it is. If the answer is "two of them", that is two flags.
2. Blast radius if the new path misbehaves (cosmetic / degraded / data-corrupting / revenue-affecting).
3. Bucketing key - usually user id; sometimes account id so a whole team sees one variant.
4. Owner (a person, not a team) and the removal condition.
5. Safe default - the value served if the flag service is unreachable.
### Step 2: Classify the flag - lifecycle follows type
- Release flag: gates unfinished or risky features during rollout. Lifetime: days to weeks. Removal deadline set at creation, maximum 90 days out; most should die within 30 days of full rollout.
- Ops flag / kill switch: disables a feature or dependency during an incident. Long-lived by design, but the inventory must stay small (a service with 50 kill switches has 50 untested code paths) and each must be re-tested on a schedule - flip it in staging at least quarterly, because an untested kill switch fails exactly when you need it.… load the full skill through Skill MeClick to play with sound.