> feature-flag-manager

When the user needs to implement feature flags, gradual rollouts, or experiment bucketing. Use when the user mentions "feature flag," "feature toggle," "gradual rollout," "canary release," "percentage rollout," "kill switch," "user bucketing," "experiment assignment," or "dark launch." Covers flag evaluation, deterministic user assignment, targeting rules, and flag lifecycle management. For experiment design, see ab-test-setup. For event tracking, see analytics-tracking.

fetch
$curl "https://skillshub.wtf/TerminalSkills/skills/feature-flag-manager?format=md"
SKILL.mdfeature-flag-manager

Feature Flag Manager

Overview

Implements feature flag systems for controlled rollouts and A/B testing. Covers flag definition, deterministic user bucketing (same user always sees the same variant), attribute-based targeting, percentage rollouts, and flag lifecycle management. Builds self-hosted solutions — no third-party dependencies.

Instructions

1. Flag Definition Schema

interface FeatureFlag {
  key: string;              // "checkout-redesign"
  type: 'boolean' | 'multivariate';
  enabled: boolean;         // Global kill switch
  variants: string[];       // ["control", "new-checkout"]
  allocation: number[];     // [50, 50] — percentage per variant
  targeting?: TargetingRule[];
  createdAt: Date;
  updatedAt: Date;
}

interface TargetingRule {
  attribute: string;        // "plan", "country", "signupDate"
  operator: 'eq' | 'neq' | 'in' | 'gt' | 'lt' | 'contains';
  values: any[];
  allocation?: number[];    // Override allocation for this segment
}

Store flags in database with in-memory cache (refresh every 30 seconds or on webhook).

2. Deterministic Bucketing

Use MurmurHash3 for stable, uniform distribution:

import murmurhash from 'murmurhash';

function assignVariant(flagKey: string, userId: string, variants: string[], allocation: number[]): string {
  const hash = murmurhash.v3(flagKey + ':' + userId);
  const bucket = hash % 10000; // 0-9999 for 0.01% granularity
  
  let cumulative = 0;
  for (let i = 0; i < variants.length; i++) {
    cumulative += allocation[i] * 100; // Convert percentage to basis points
    if (bucket < cumulative) return variants[i];
  }
  return variants[0]; // Fallback to first variant
}

Properties:

  • Deterministic: Same user + same flag = same variant, always
  • Independent: Different flags produce independent assignments
  • Uniform: MurmurHash3 distributes evenly across buckets
  • Stable on resize: Changing 50/50 to 70/30 keeps most users in their original bucket

3. Flag Evaluation Pipeline

evaluateFlag(flagKey, userId, userAttributes):
  1. Load flag config from cache
  2. If flag.enabled === false → return default variant (control)
  3. Check targeting rules in order:
     - If user matches a rule → use that rule's allocation
     - If no rules match → use default allocation
  4. Compute bucket via deterministic hash
  5. Map bucket to variant via allocation percentages
  6. Log assignment event (for analytics)
  7. Return variant name

4. Server-Side Integration

// Express middleware — evaluate all active flags per request
app.use((req, res, next) => {
  const userId = req.user?.id || req.cookies.anonymousId;
  const attributes = {
    plan: req.user?.plan,
    country: req.headers['cf-ipcountry'],
    signupDate: req.user?.createdAt,
  };
  req.flags = evaluateAllFlags(userId, attributes);
  next();
});

// In route handler
app.get('/checkout', (req, res) => {
  if (req.flags['checkout-redesign'] === 'new-checkout') {
    return renderNewCheckout(req, res);
  }
  return renderCurrentCheckout(req, res);
});

5. Flag Lifecycle

1. CREATED — Flag defined, enabled=false, no traffic
2. TESTING — Enabled for internal users via targeting (email contains @company.com)
3. RAMPING — Gradual rollout: 5% → 25% → 50% → 100%
4. DECIDED — Experiment concluded, winner at 100%
5. ARCHIVED — Flag code removed, config kept for audit trail

Track lifecycle in database. Alert when flags are in DECIDED state for > 14 days (cleanup reminder).

6. Admin API

GET    /api/flags                    — List all flags
POST   /api/flags                    — Create flag
PATCH  /api/flags/:key               — Update allocation/targeting
PATCH  /api/flags/:key/toggle        — Enable/disable (kill switch)
GET    /api/flags/:key/assignments   — View user distribution
DELETE /api/flags/:key               — Archive flag

Examples

Example 1: Boolean Feature Flag

Prompt: "Add a feature flag for our new search bar. Roll out to 10% of users first."

Output: Flag definition with boolean type, 90/10 allocation, evaluation middleware, and admin toggle endpoint.

Example 2: Multi-Variant Experiment

Prompt: "Test three pricing page layouts: current, simplified, and detailed. Only for US users on free plan."

Output: Multivariate flag with targeting rules (country=US, plan=free), three-way allocation (34/33/33), bucketing implementation, and assignment logging for analytics.

Guidelines

  • Always use server-side evaluation — client-side flags leak experiment details and flicker
  • Hash with experiment key — ensures independent randomization across experiments
  • Cache flag configs — don't query database on every request; 30s TTL is fine
  • Log every assignment — needed for experiment analysis; include flag, variant, userId, timestamp
  • Build a kill switchenabled: false must immediately disable the flag globally
  • Clean up old flags — stale flags become tech debt; alert after 14 days post-decision
  • Test the bucketing — verify distribution is uniform with 10K+ simulated users before shipping
  • Support anonymous users — use a cookie-based anonymous ID for pre-login bucketing

> related_skills --same-repo

> zustand

You are an expert in Zustand, the small, fast, and scalable state management library for React. You help developers manage global state without boilerplate using Zustand's hook-based stores, selectors for performance, middleware (persist, devtools, immer), computed values, and async actions — replacing Redux complexity with a simple, un-opinionated API in under 1KB.

> zoho

Integrate and automate Zoho products. Use when a user asks to work with Zoho CRM, Zoho Books, Zoho Desk, Zoho Projects, Zoho Mail, or Zoho Creator, build custom integrations via Zoho APIs, automate workflows with Deluge scripting, sync data between Zoho apps and external systems, manage leads and deals, automate invoicing, build custom Zoho Creator apps, set up webhooks, or manage Zoho organization settings. Covers Zoho CRM, Books, Desk, Projects, Creator, and cross-product integrations.

> zod

You are an expert in Zod, the TypeScript-first schema declaration and validation library. You help developers define schemas that validate data at runtime AND infer TypeScript types at compile time — eliminating the need to write types and validators separately. Used for API input validation, form validation, environment variables, config files, and any data boundary.

> zipkin

Deploy and configure Zipkin for distributed tracing and request flow visualization. Use when a user needs to set up trace collection, instrument Java/Spring or other services with Zipkin, analyze service dependencies, or configure storage backends for trace data.

┌ stats

installs/wk0
░░░░░░░░░░
github stars17
███░░░░░░░
first seenMar 17, 2026
└────────────

┌ repo

TerminalSkills/skills
by TerminalSkills
└────────────

┌ tags

└────────────