manage-feature-flags

Manage Feature Flags

Engine required — resolve an engine per ENGINE.md: one named in the conversation or loaded instructions is mandatory (not set up → offer /mixpanel:install for it); otherwise use the Mixpanel MCP server, or offer /mixpanel:install if it's unavailable.

Coach the user through Mixpanel feature-flag work end-to-end: routing the request to the right flag-shaped product, ramping safely, killing fast when something goes wrong, and cleaning up when iteration is done.

The single most important idea: a flag's on/off state and its rollout percentage are different levers. The on/off state is the kill switch (instant). The rollout percentage is the throttle (gradient). Most flag bugs come from confusing the two; use the right lever for each step.

Requirements

• Access to Mixpanel (read, create, update, list, and archive feature flags).
• For experiment-backed flags, the ability to create and update experiments — see references/experiment-linked-flags.md.

When to use this skill

Trigger when the user asks anything about creating, configuring, ramping, killing, archiving, debugging, or cleaning up Mixpanel feature flags. Common phrasings:

• "Create a feature flag for <feature>"
• "Roll this out to 10% of users"
• "Kill the flag" / "turn it off"
• "Why doesn't anyone see my flag?" / "I bumped the rollout but nothing changed"
• "Why are there zero exposure events?"
• "Should this be a feature flag or an experiment?"
• "Archive all our stale flags" / "what's our flag debt?"
• "Roll back to 0%" / "restore an archived flag"

Do not trigger for experiment design ("how should I size this A/B test?", "what's my MDE?"), launch, mid-flight monitoring, or results interpretation ("should we ship this experiment?", "what does this SRM failure mean?") — all of those belong to the manage-experiment skill.

---

Glossary

• Feature Gate — an on/off toggle that serves one of two boolean variants per user. Kill switches, gradual rollouts, geo gates, internal-only enables. Control is the variant that means "feature off."
• Dynamic Config — a flag that serves a payload (string or structured object) per user without measurement. Copy variations, theme keys, configuration objects.
• Experiment — variant comparison with statistical machinery (primary metric, health checks, significance). Created via the experiment path; the backing flag is auto-created and linked.
• Kill switch — disabling an enabled flag to serve control to everyone, instantly, without losing the rollout configuration. Reversible.
• Ramp — bumping the rollout percentage upward through a staged cadence (typically 1% → 10% → 50% → 100%).
• Sticky bucketing — a user assigned to a variant stays in that variant across sessions, keyed on a stable identity (by default distinct_id).
• Exposure event — the analytics event the SDK emits when a flag is evaluated via a tracking entry point. Used to confirm the rollout is serving variants in the proportions you configured.
• Archive — a terminal cleanup operation that hides the flag from default listings and stops SDK evaluation. Reversible via restore, but destructive on a live flag — archiving a flag that still has live traffic strips its rollout state.
• Restore — the un-archive verb. A restored flag lands back in the disabled state, never directly enabled.
• Experiment-linked flag — a flag whose lifecycle is owned by an experiment. Direct flag edits are accepted but get overwritten on the next experiment transition. Route changes through the experiment.