Feature Flag Planner

When to use

Use this skill when introducing feature flags to decouple deploy from release, when planning a gradual rollout or A/B test, when setting up kill switches for risky launches, or when the codebase has accumulated so many stale flags that it has become hard to reason about. Trigger when the user mentions feature flags, dark launches, canary releases, kill switches, or flag cleanup.

Inputs to gather

• The flag management system (LaunchDarkly, Flagsmith, Unleash, in-house, env-var based)
• The engineering and release cadence (continuous deploy, scheduled releases)
• Whether experimentation/A/B testing is needed, or just release flags
• Targeting dimensions: user id, account/tier, geography, device, custom attributes
• The user identification and anonymity model (logged-in vs anonymous)
• Risk profile of the features being flagged (reversible, data-migrating, payments)
• Team structure and who owns which flags
• Existing flag debt: count of flags in the codebase and their ages

Procedure

1. Classify each flag by type and lifespan. Release flags (short-lived, removed after full rollout), experiment flags (A/B tests, removed after the experiment concludes), ops/kill-switch flags (long-lived, for emergency disabling), permission flags (long-lived entitlement gating). The type dictates lifespan and cleanup expectations — never create a flag without recording its type and intended retirement condition.
2. Choose a deterministic bucketing strategy. For percentage rollouts, hash a stable identifier (user id, account id) into a 0–99 bucket and enable the flag for buckets below the threshold. Ensure the hashing is deterministic so a given user always sees the same variant across sessions and services. For anonymous users, use a stable device cookie, not the session, to avoid flipping.
3. Design targeting rules before rollout. Define who gets the flag first: internal dogfooding (employee accounts), then a specific beta cohort, then a percentage of the population, then 100%. Make targeting composable (AND/OR rules on attributes) and testable against a sample user before applying. Document the intended rollout staircase.
4. Build in a kill switch from the start. Every risky feature should have a flag that can be turned off globally within seconds, without a deploy, by an on-call engineer. The kill switch path must be tested (turn it off in staging, confirm the fallback works). For critical paths, ensure the system degrades gracefully if the flag service is unavailable (fail-open or fail-closed per the feature's risk).
5. Manage flag dependencies. When feature B depends on feature A being enabled, encode the dependency in the flag config or runtime check so B cannot be enabled without A. Document the dependency graph; a tangled web of interdependent flags is a common source of confusing production states.
6. Instrument flag state in observability. Log the flag evaluations (flag key, user, variant) into your analytics and include them in traces and logs on every request. When an incident occurs, you must be able to see which flags were active for affected users. Segment all business metrics by flag variant so you can compare outcomes during a rollout.
7. Schedule cleanup at creation time. Every release and experiment flag gets a ticket for removal created when the flag is added, with a target date (e.g., two weeks after planned full rollout). Add a flag-age metric to a dashboard and a recurring cleanup task. Long-lived flags add branching complexity and test burden — each is technical debt accruing interest.
8. Write code that assumes flags go away. Avoid putting complex logic inside flag checks that becomes load-bearing. Prefer to refactor the codebase to the new behavior and use the flag only to gate the entry point, so removal is a one-line deletion, not an archaeology project.

Output format

A feature-flag strategy document with: the flag taxonomy and lifespan rules, the deterministic bucketing and targeting scheme, the per-flag rollout staircase and kill-switch plan, the dependency graph, the observability instrumentation requirements, and the cleanup schedule with auto-created removal tickets.

Common pitfalls

• Creating release flags with no removal plan, leaving dead branches in the codebase for years.
• Using a non-deterministic or session-based bucketing key, so users flip between variants and see inconsistent behavior.
• Putting substantial logic inside flag branches, making the flag impossible to remove without a rewrite.
• Not testing the kill-switch/off path, so disabling the flag in an incident causes a new failure.
• Letting flag dependencies become implicit, producing impossible production states.
• Failing closed on a critical feature when the flag service has an outage, causing an outage of the feature itself.