| name | feature-flags |
| description | Feature flags and toggles management. Trigger when the user wants to implement feature flagging, A/B testing, or progressive deployment. |
| allowed-tools | ["Read","Write","Edit","Glob","Grep"] |
| context | fork |
| user-invocable | false |
Feature Flags (pointer)
SDK code, targeting rules syntax and dashboard integration drift on each vendor release and are canonical at:
Use-case taxonomy (version-agnostic)
| Type | Purpose | Lifetime |
|---|
| Release toggle | Deploy inactive code; flip on after smoke test | Short (days/weeks) |
| Experiment toggle | A/B test; emits exposure events for analysis | Bounded by experiment duration |
| Ops toggle | Circuit breakers, kill switches, degraded modes | Long-lived |
| Permission toggle | Feature gating by role/plan/cohort | Permanent (treat like config) |
Choose by lifetime: short → cheap implementation, long-lived → invest in observability + naming discipline.
Foundation discipline (keep across releases)
- Default OFF: every flag defaults to its conservative value (usually off). A flag that ships defaulting to ON is a hidden behaviour change.
- 2-sprint rule: remove release toggles within 2 sprints of full rollout. Stale flags accrue as tech debt — surface them via
qa-tech-debt.
- Log every evaluation: missing evaluation logs make debugging "why did user X see variant Y" impossible. Vendor SDKs offer this; if rolling custom, log it.
- No business logic in flag values: a flag is a boolean (or enum); complex conditions belong in code paths the flag selects, not inside the flag service.
- Naming convention:
<scope>_<feature>_<variant> (e.g. checkout_express_enabled). Scope-first sorts/filters cleanly in dashboards.
See also
growth-ab-test skill — experiment design, sample-size, exposure analysis (consumes experiment toggles)qa-tech-debt — flag-debt scan surfaces stale flags past the 2-sprint windowdev-tdd — flag-gated code paths must be tested in BOTH states (on/off), not just the new path
