Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →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.
.claude/skills/borghei-feature-flag-strategy/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-16 | ✗→✓ | ▲ Improved | 95% | 0% |
| case-22 | ✗→✓ | ▲ Improved | 72% | 0% |
| case-10 | ✓→✓ | ＝ Same ✓ | 102% | 0% |
| case-07 | ✓→✓ | ＝ Same ✓ | 169% | 0% |
| case-08 | ✓→✓ | ＝ Same ✓ | 79% | 0% |
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.
ai-feature-prd/; cost gates via engineering/llm-cost-optimizer/).When NOT to use: one-time data migrations (use a script with --dry-run), environment configuration, permanent A/B variants that never converge (that is personalization), or flag-flagging every change (cost > value when overused).
Before drafting the rollout plan, confirm these inputs. If any is unknown or vague, ASK — do not assume:
Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact.
assets/rollout_plan_template.md.See references/rollout-execution-playbook.md for the full taxonomy, shape catalog, kill-switch tree, holdout governance, naming, workflow, troubleshooting, and success criteria.
references/rollout-execution-playbook.md -- read this when planning a rollout end-to-end: flag taxonomy, all 7 rollout shapes, kill-switch decision tree + thresholds, holdouts, flag-debt retirement, naming, dependency chains, approval/audit, workflow, troubleshooting, success criteria.references/fowler-feature-toggle-taxonomy-guide.md -- read this for the deep dive on Martin Fowler's "Feature Toggles" essay, lifespans, ownership patterns, and the operational discipline behind them.references/rollout-shape-comparison-guide.md -- read this for the worked comparison of the 7 rollout shapes with example use cases and risk profiles.references/red-flags.md -- read this when reviewing a rollout plan for anti-patterns and failure modes before sign-off.assets/rollout_plan_template.md -- per-feature rollout plan with stages, gates, owners, dates.assets/kill_switch_decision_tree.md -- pre-incident kill-switch thresholds + authority + flip steps.assets/flag_debt_retirement_checklist.md -- retirement workflow + quarterly audit.assets/flag_naming_convention.md -- team naming sheet.In scope: flag taxonomy and lifespan rules; rollout shapes; kill-switch decision tree and thresholds; holdout design; flag-debt retirement workflow + audit; naming and dependency-chain governance; approval, audit-trail, and two-person-rule patterns.
Out of scope: wiring flag SDKs into a codebase (engineering side); statistical analysis of experiments (pair with discovery/brainstorm-experiments/ for design; data-analytics for stats); building gating dashboards (BI tooling); customer launch comms (launch-playbook/, prfaq/, release-notes/); end-of-life narrative (eol-communication/); code rollback strategy (git revert + deployment pipelines).
Caveats: flags reduce launch risk but do not eliminate it -- a flag with a broken kill-switch is worse than no flag. Flag debt grows with velocity. Permission/Ops flags are permanent; release/experiment flags are temporary, and conflating the two is the most common failure mode. Holdouts are politically hard to maintain -- document the policy with leadership sign-off. On mobile, forced-upgrade flows are user-hostile; plan around adoption curves.
| Integration | Direction | Description | |---|---|---| | launch-playbook/ | Pairs with | Rollout plan is the deployment ramp inside the broader launch playbook | | cycle-time-analyzer/ | Pairs with | Long-stuck ramps are a leading indicator of risk | | prfaq/ / release-notes/ | Pairs with | External launch narrative vs the operational rollout plan that produced it | | eol-communication/ | Pairs with | Reverse-ramp (Shape F) is the operational side of a sunset | | ai-feature-prd/ | Pairs with | The AI PRD's deployment ramp (Section 11.3) executes via this skill | | discovery/brainstorm-experiments/ | Pairs with | Experiment toggles operationalize Lean experiments | | discovery/pre-mortem/ | Pairs with | Pre-mortem risks inform kill-switch thresholds | | engineering/llm-cost-optimizer/ | Pairs with | AI ramp gate: cost budget per stage | | status-update-generator/ | Feeds into | Rollout-stage pace + gates appear in weekly status |
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-10 | pass→pass | 14,904 | 17,662 | +19% | 1 | 1 | 0% | 2,153 | 4,343 | +102% | 0 | 0 | — |
case-01 | fail→fail | 23,942 | 28,313 | +18% | 1 | 1 | 0% | 3,730 | 6,352 | +70% | 0 | 0 | — |
case-02 | fail→fail | 21,481 | 26,064 | +21% | 1 | 1 | 0% | 3,328 | 5,777 | +74% | 0 | 0 | — |
case-03 | fail→fail | 27,081 | 28,942 | +7% | 1 | 1 | 0% | 4,339 | 6,146 | +42% | 0 | 0 | — |
case-04 | fail→fail | 15,472 | 12,991 | -16% | 1 | 1 | 0% | 2,739 | 3,982 | +45% | 0 | 0 | — |
case-05 | fail→fail | 15,981 | 17,892 | +12% | 1 | 1 | 0% | 3,474 | 5,516 | +59% | 0 | 0 | — |
case-06 | fail→fail | 14,666 | 18,098 | +23% | 1 | 1 | 0% | 2,153 | 4,300 | +100% | 0 | 0 | — |
case-07 | pass→pass | 19,698 | 19,807 | +1% | 1 | 1 | 0% | 1,676 | 4,505 | +169% | 0 | 0 | — |
case-08 | pass→pass | 14,682 | 14,771 | +1% | 1 | 1 | 0% | 2,143 | 3,828 | +79% | 0 | 0 | — |
case-09 | pass→pass | 11,307 | 20,821 | +84% | 1 | 1 | 0% | 1,703 | 4,826 | +183% | 0 | 0 | — |
case-11 | pass→pass | 14,007 | 17,674 | +26% | 1 | 1 | 0% | 2,023 | 4,464 | +121% | 0 | 0 | — |
case-12 | pass→pass | 14,817 | 21,884 | +48% | 1 | 1 | 0% | 2,242 | 5,091 | +127% | 0 | 0 | — |
case-13 | pass→pass | 12,690 | 16,613 | +31% | 1 | 1 | 0% | 1,784 | 4,227 | +137% | 0 | 0 | — |
case-14 | pass→pass | 13,398 | 18,203 | +36% | 1 | 1 | 0% | 2,030 | 4,422 | +118% | 0 | 0 | — |
case-15 | pass→pass | 12,187 | 16,465 | +35% | 1 | 1 | 0% | 1,892 | 4,267 | +126% | 0 | 0 | — |
case-16 | fail→pass | 14,932 | 17,896 | +20% | 1 | 1 | 0% | 2,276 | 4,428 | +95% | 0 | 0 | — |
case-17 | pass→pass | 13,203 | 18,894 | +43% | 1 | 1 | 0% | 1,923 | 4,367 | +127% | 0 | 0 | — |
case-18 | pass→pass | 9,630 | 16,927 | +76% | 1 | 1 | 0% | 1,373 | 4,222 | +208% | 0 | 0 | — |
case-19 | pass→pass | 7,401 | 15,000 | +103% | 1 | 1 | 0% | 1,197 | 3,971 | +232% | 0 | 0 | — |
case-20 | pass→pass | 13,813 | 15,454 | +12% | 1 | 1 | 0% | 2,143 | 3,931 | +83% | 0 | 0 | — |
case-21 | pass→pass | 13,102 | 17,003 | +30% | 1 | 1 | 0% | 1,931 | 4,225 | +119% | 0 | 0 | — |
case-22 | fail→pass | 13,711 | 12,147 | -11% | 1 | 1 | 0% | 2,050 | 3,520 | +72% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +9 percentage points is the difference between those two pass rates over the 22 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.