Agent skill · product strategy · borghei
feature-flag-strategy
PM-facing playbook for phased rollouts with feature flags -- taxonomy (release / experiment / ops / permission), rollout shapes, kill-switch decision tree, holdouts, flag debt retirement, and naming conventions.
Why this skill is useful
Provides a structured playbook for managing feature flags that includes specific rollout strategies and governance practices not commonly known.
What it needs
About 4k tokens when loaded. Last updated 2026-07-21. 462 stars on the source repository.
What this skill does
Feature Flag Strategy (PM playbook) Overview A feature flag is a runtime switch that decouples deploying code from releasing a feature. Done well, flags turn high-stakes ship dates into low-stakes config changes -- launches become measured ramps, regressions become single-toggle rollbacks, and experiments live alongside production code. Done poorly, flags become permanent technical debt: hundreds of dead toggles in code, conflicting flag states across environments, and nobody remembering what the flag controls. This skill is the PM-facing rollout playbook. It does not describe how to wire a flag library into your codebase (that is the engineering side, e.g. your LaunchDarkly / Statsig / Optimizely / Unleash / OpenFeature install). It describes how a PM plans a phased rollout: what kind of flag this is, how it ramps, what the gate criteria are between stages, who can flip the kill-switch, when the flag retires, and how it is named so the team can find it six months later. The frameworks behind it are Martin Fowler's "Feature Toggles" taxonomy, LaunchDarkly's rollout best practices, Optimizely / Statsig experiment playbooks, and Reforge experimentation foundations. Core Capabilities Flag classification -- release / experiment / ops / permission, each with its own lifespan and ownership rules. Rollout shape selection -- linear, segmented, geographic, A/B-with-holdout, dark launch, reverse ramp, mobile forced-upgrade. Kill-switch design -- pre-agreed thresholds per surface and single-config-change rollback authority for on-call. Holdout design -- short-term and global holdouts for long-term lift attribution. Flag-debt governance -- retirement dates, retirement checklist, quarterly audit, naming conventions, dependency chains. When to Use Planning a launch larger than a small team can ship cold (anything customer-facing usually warrants a flag). Risky changes to high-traffic surfaces (search, checkout, auth, billing -- always behind a kill-switch). …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills borghei/feature-flag-strategy