feature-flag-management

name	feature-flag-management
description	Feature flag lifecycle management -- safe feature toggling, gradual rollouts, A/B testing patterns, flag cleanup strategies, and technical debt prevention. Covers LaunchDarkly, Unleash, OpenFeature, and custom implementations.
version	2.0.0
category	DevOps
agents	["developer","devops","qa"]
tags	["feature-flags","rollouts","a-b-testing","toggles","launchdarkly","openfeature","trunk-based-development"]
model	sonnet
invoked_by	both
user_invocable	true
tools	["Read","Write","Edit","Bash","Glob","Grep","WebFetch"]
best_practices	["Define a clear lifecycle for every flag (create, enable, rollout, permanent, cleanup)","Use typed flag values with defaults that match the safe/existing behavior","Clean up flags within 30 days of full rollout to prevent technical debt","Never nest feature flags more than 2 levels deep","Always include kill-switch capability for new features behind flags"]
error_handling	graceful
streaming	supported
verified	true
lastVerifiedAt	2026-03-01
source	builtin
trust_score	100
provenance_sha	e91a4c35aa7c28e0

Feature Flag Management Skill

Feature flag lifecycle specialist covering safe feature toggling, gradual rollouts, A/B testing patterns, and flag cleanup to prevent technical debt. Enforces disciplined flag hygiene across the full lifecycle from creation through retirement. - Design feature flag architecture with proper categorization (release, experiment, ops, permission) - Implement gradual rollout strategies (percentage, user-segment, canary, ring-based) - Configure A/B testing with feature flags and metrics collection - Plan flag cleanup workflows to prevent stale flag accumulation - Integrate with flag platforms (LaunchDarkly, Unleash, Flipt, OpenFeature SDK) - Implement custom feature flag systems for projects without external platforms - Set up flag-aware testing strategies (all flag combinations) - Monitor flag evaluation performance and stale flag detection

Overview

Feature flags decouple deployment from release, enabling trunk-based development, safe rollouts, and instant rollbacks. However, undisciplined flag usage creates exponential code path complexity, stale flags, and untested combinations. This skill enforces a lifecycle-driven approach: every flag has a type, an owner, a target date, and a cleanup plan from day one.

When to Use

• When implementing trunk-based development with continuous deployment
• When rolling out features gradually to reduce risk
• When setting up A/B testing infrastructure
• When auditing existing codebases for stale or orphaned feature flags
• When choosing between feature flag platforms
• When implementing kill-switches for critical features

Iron Laws

1. ALWAYS assign an owner and expiration date to every feature flag -- orphaned flags without owners accumulate indefinitely and become permanent tech debt.
2. NEVER nest feature flags more than 2 levels deep -- combinatorial explosion makes testing impossible (2 flags = 4 states, 5 flags = 32 states, 10 flags = 1024 states).
3. ALWAYS default flag values to the existing/safe behavior -- if the flag system fails, the application should behave as it did before the flag was added.
4. NEVER use feature flags as a substitute for configuration management -- flags are temporary toggles for release control, not permanent application settings.
5. ALWAYS clean up flags within 30 days of full rollout -- stale flags in code increase cognitive load, slow onboarding, and hide dead code paths.

Anti-Patterns

Anti-Pattern	Why It Fails	Correct Approach
Creating flags without expiration dates or owners