AutoGineer
Generated banner for Instrument Feature Flags
Generated logo for Instrument Feature Flags

Instrument Feature Flags

PostHogOfficialCreated by PostHog

  • Skill
  • Tool integration
  • Data and AI
  • MIT
  • Low risk
Download ZIP

From the author

Add PostHog feature flags to gate new functionality. Use after implementing features or reviewing PRs to ensure safe rollouts with feature flag controls. Also handles initial PostHog SDK setup if not yet installed.
— the description by PostHog

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to instrumenting PostHog feature flags within your codebase. It handles the end-to-end process, including detecting your platform, setting up the PostHog SDK if necessary, configuring environment variables, and implementing the code required to gate features. It emphasizes best practices such as using environment variables for configuration, preferring server-side evaluation to prevent UI flicker, and ensuring minimal, non-intrusive code changes.

What it does

  • Detects your project's platform and language automatically.
  • Initializes the PostHog SDK if it is not already present in the project.
  • Configures required environment variables securely without hardcoding.
  • Provides platform-specific code patterns for implementing feature flag checks.
  • Guides the integration of boolean and multivariate feature flags.
  • Ensures PostHog configuration does not break application boot or runtime stability.

When to use it

  • When you need to gate new functionality for controlled releases.
  • After implementing a new feature that requires a safe rollout strategy.
  • When reviewing pull requests that introduce features needing toggle controls.
  • When you need to set up PostHog instrumentation in a new or existing project.

Advantages

  • Supports a wide range of languages, frameworks, and platforms.
  • Promotes safe, production-ready instrumentation patterns.
  • Prevents common issues like UI flicker through server-side evaluation.
  • Maintains clean code by avoiding hardcoded configuration keys.

Usage examples

“Add a PostHog feature flag to gate the new checkout button in my React app.”
The agent will analyze your React project, verify PostHog setup, and provide the code snippet using posthog.isFeatureEnabled to conditionally render the button.
“I need to instrument a new feature flag for my Node.js backend.”
The agent will detect the Node.js environment, ensure the SDK is initialized, and guide you through adding the flag check logic to your server-side code.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/posthog/instrument-feature-flags/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip instrument-feature-flags.zip -d .agents/skills

Documentation by PostHog

Add PostHog feature flags

Use this skill to add PostHog feature flags that gate new or changed functionality. Use it after implementing features or reviewing PRs to ensure safe rollouts with feature flag controls. If PostHog is not yet installed, this skill also covers initial SDK setup. Supports any platform or language.

Supported platforms: React, Next.js, React Native, Web (JavaScript), Node.js, Python, PHP, Ruby, Go, Java, Rust, .NET, Elixir, Android, iOS, Flutter, and the REST API.

Instructions

Follow these steps IN ORDER:

STEP 1: Analyze the codebase and detect the platform.

Look for dependency files (package.json, pubspec.yaml, Podfile, Package.swift, requirements.txt, go.mod, Gemfile, composer.json, mix.exs, etc.) to determine the language and framework.

Look for lockfiles (pnpm-lock.yaml, package-lock.json, yarn.lock, bun.lockb, go.sum, pubspec.lock, Podfile.lock, Package.resolved, mix.lock) to determine the package manager.

  • Check for existing PostHog setup (SDK initialization, env vars, etc.). If PostHog is already installed and initialized, skip to STEP 3.

STEP 2: Research instrumentation. (Skip if PostHog is already set up.) 2.1. Find the reference file below that matches the detected platform — it is the source of truth for SDK initialization, flag evaluation methods, and framework-specific patterns. Read it now. 2.2. If no reference matches, fall back to your general knowledge and web search. Use posthog.com/docs as the primary search source.

STEP 3: Create or find the feature flag.

  • Check if a PostHog MCP server is connected. If available, use its tools to search for an existing feature flag the user wants to instrument, or create a new one.

  • If no MCP server is available, instruct the user to create the flag in the PostHog dashboard.

STEP 4: Plan release conditions.

  • Determine the rollout strategy (percentage rollout, user targeting, group targeting, etc.).

  • Plan how the feature flag will gate the new functionality in code.

STEP 5: Instrument the feature.

  • Add the feature flag code following the platform-specific reference patterns.

  • Use server-side evaluation when possible to avoid UI flicker.

  • Do not alter the fundamental architecture of existing files. Make additions minimal and targeted.

  • You must read a file immediately before attempting to write it.

STEP 6: Set up environment variables.

  • Check if the project already has PostHog environment variables configured (e.g. in .env, .env.local, or framework-specific env files). If valid values already exist, skip this step.

  • If the PostHog project token is missing, use the PostHog MCP server's projects-get tool to retrieve the project's api_token. If multiple projects are returned, ask the user which project to use. If the MCP server is not connected or not authenticated, ask the user for their PostHog project token instead.

  • For the PostHog host URL: check the projects-get MCP response for a region field — US maps to https://us.i.posthog.com, EU maps to https://eu.i.posthog.com. If the region is not available from the MCP response or from existing project configuration, ask the user: "Are you on PostHog US Cloud or EU Cloud?" Do not assume US Cloud.

  • Write these values to the appropriate env file using the framework's naming convention.

  • Reference these environment variables in code instead of hardcoding them.

Reference files

  • references/react.md - React feature flags installation

  • references/react-native.md - React native feature flags installation

  • references/web.md - Web feature flags installation

  • references/nodejs.md - Node.js feature flags installation

  • references/python.md - Python feature flags installation

  • references/django.md - Django

  • references/flask.md - Flask

  • references/php.md - Php feature flags installation

  • references/laravel.md - Laravel

  • references/ruby.md - Ruby feature flags installation

  • references/ruby-on-rails.md - Ruby on rails

  • references/go.md - Go feature flags installation

  • references/java.md - Java feature flags installation

  • references/rust.md - Rust feature flags installation

  • references/dotnet.md - .net feature flags installation

  • references/dotnet.md - .net

  • references/elixir.md - Elixir feature flags installation

  • references/android.md - Android feature flags installation

  • references/ios.md - Ios feature flags installation

  • references/usage.md - Ios SDK usage

  • references/flutter.md - Flutter feature flags installation

  • references/api.md - API feature flags installation

  • references/next-js.md - Next.js

  • references/adding-feature-flag-code.md - Adding feature flag code

  • references/best-practices.md - Best practices for production-ready flags

  • references/COMMANDMENTS.md - Framework-specific rules the integration must follow

Each platform reference contains SDK-specific installation, flag evaluation, and code examples. Find the one matching the user's stack. If unlisted, use the API reference as a fallback.

Key principles

  • Environment variables: Always use environment variables for PostHog keys. Never hardcode them.

  • Minimal changes: Add feature flag code alongside existing logic. Don't replace or restructure existing code.

  • Boolean flags first: Default to boolean flag checks unless the user specifically asks for multivariate flags.

  • Server-side when possible: Prefer server-side flag evaluation to avoid UI flicker.

Files

references/rust.md

AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

Rust Feature Flags installation

Canonical URL: https://posthog.com/docs/feature-flags/installation/rust

Install with the wizard

Run this command in your project directory to add PostHog to your Rust project. The wizard detects your framework, installs the SDK, and sets up your first events.

npx @posthog/wizard

Or set it up manually by following the rest of this guide.

Install the posthog-rs crate by adding it to your Cargo.toml.

Cargo.toml

[dependencies]
posthog-rs = "0.14"

Next, set up the client with your PostHog project key.

let client = posthog_rs::client("<ph_project_token>").await;
Blocking client

Our Rust SDK supports both blocking and async clients. The async client is the default and is recommended for most use cases.

If you need to use a synchronous client instead – like we do in our CLI –, you can opt into it by disabling the asynchronous feature on your Cargo.toml file.

[dependencies]
posthog-rs = { version = "0.14", default-features = false }

With the blocking client, the same methods are available without .await. Either way, capture is non-blocking: it hands the event to a background worker that batches and sends it, so it returns immediately instead of waiting on the network. Because delivery happens in the background, call flush() or shutdown() before your program exits, or buffered events may be lost.

Using feature flags

There are two steps to implement feature flags in Rust:

Step 1: Evaluate flags once

Call client.evaluate_flags() once for the user, then read values from the returned snapshot.

Boolean feature flags
use posthog_rs::EvaluateFlagsOptions;

let flags = client.evaluate_flags(
    "distinct_id_of_your_user",
    EvaluateFlagsOptions::default(),
).await.unwrap();

if flags.is_enabled("flag-key") {
    // Do something differently for this user
    // Optional: fetch the payload
    let matched_flag_payload = flags.get_flag_payload("flag-key");
}
Multivariate feature flags
use posthog_rs::{EvaluateFlagsOptions, FlagValue};

let flags = client.evaluate_flags(
    "distinct_id_of_your_user",
    EvaluateFlagsOptions::default(),
).await.unwrap();

match flags.get_flag("flag-key") {
    Some(FlagValue::String(variant)) if variant == "variant-key" => {
        // Do something differently for this user
        // Optional: fetch the payload
        let matched_flag_payload = flags.get_flag_payload("flag-key");
    }
    _ => {}
}

flags.get_flag() returns Some(FlagValue::String(...)) for multivariate flags, Some(FlagValue::Boolean(true)) for enabled boolean flags, Some(FlagValue::Boolean(false)) for disabled flags, and None when the flag wasn't returned by the evaluation.

Note: client.is_feature_enabled(), client.get_feature_flag(), client.get_feature_flag_payload(), and client.get_feature_flags() still work during the migration period, but they're deprecated. Prefer evaluate_flags() for new code.

Step 2: Include feature flag information when capturing events

If you want use your feature flag to breakdown or filter events in your insights, you'll need to include feature flag information in those events. This ensures that the feature flag value is attributed correctly to the event.

Note: This step is only required for events captured using our server-side SDKs or API.

There are two methods you can use to include feature flag information in your events:

Method 1: Pass the evaluated flags snapshot to the event

Pass the same flags object that you used for branching. This attaches the exact flag values from that evaluation and doesn't make another /flags request.

use posthog_rs::{EvaluateFlagsOptions, Event};

let flags = client.evaluate_flags(
    "distinct_id_of_your_user",
    EvaluateFlagsOptions::default(),
).await.unwrap();

if flags.is_enabled("flag-key") {
    // Do something differently for this user
}

let mut event = Event::new("event_name", "distinct_id_of_your_user");
event.with_flags(&flags);
client.capture(event);

By default, this attaches every flag in the snapshot using $feature/<flag-key> properties and $active_feature_flags.

To reduce event property bloat, pass a filtered snapshot:

// Attach only flags accessed with is_enabled() or get_flag() before this call
let mut event = Event::new("event_name", "distinct_id_of_your_user");
event.with_flags(&flags.only_accessed());
client.capture(event);

// Attach only specific flags
let mut event = Event::new("event_name", "distinct_id_of_your_user");
event.with_flags(&flags.only(&["checkout-flow", "new-dashboard"]));
client.capture(event);

only_accessed() is order-dependent. If you call it before accessing any flags with is_enabled() or get_flag(), no feature flag properties are attached.

Method 2: Include the $feature/feature_flag_name property manually

In the event properties, include $feature/feature_flag_name: variant_key:

use posthog_rs::Event;

let mut event = Event::new("event_name", "distinct_id_of_your_user");
event.insert_prop("$feature/feature-flag-key", "variant-key").unwrap();
client.capture(event);
Evaluating only specific flags

By default, evaluate_flags() evaluates every flag for the user. If you only need a few flags, pass flag_keys to request only those flags:

use posthog_rs::EvaluateFlagsOptions;

let flags = client.evaluate_flags(
    "distinct_id_of_your_user",
    EvaluateFlagsOptions {
        flag_keys: Some(vec!["checkout-flow".to_string(), "new-dashboard".to_string()]),
        ..Default::default()
    },
).await.unwrap();
Sending $feature_flag_called events

Capturing $feature_flag_called events enables PostHog to know when a flag was accessed by a user and provide analytics and insights on the flag. With evaluate_flags(), the SDK sends this event when you call flags.is_enabled() or flags.get_flag() for a flag.

The SDK deduplicates these events per (distinct_id, flag, value) in a local cache. If you reinitialize the PostHog client, the cache resets and $feature_flag_called events may be sent again. PostHog handles duplicates, so duplicate $feature_flag_called events don't affect your analytics.

flags.get_flag_payload() doesn't send $feature_flag_called events and doesn't count as an access for only_accessed().

Blocking client

If you're using the blocking client (with default-features = false), the API is the same but without .await:

use posthog_rs::EvaluateFlagsOptions;

let flags = client.evaluate_flags(
    "distinct_id_of_your_user",
    EvaluateFlagsOptions::default(),
).unwrap();

if flags.is_enabled("flag-key") {
    // Do something differently for this user
}

Now that you're evaluating flags, continue with the resources below to learn what else Feature Flags enables within the PostHog platform.

ResourceDescription
Creating a feature flagHow to create a feature flag in PostHog
Adding feature flag codeHow to check flags in your code for all platforms
Framework-specific guidesSetup guides for React Native, Next.js, Flutter, and other frameworks
How to do a phased rolloutGradually roll out features to minimize risk
More tutorialsOther real-world examples and use cases

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs Python, Needs Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
PostHog
Publisher
PostHog (Official)
Source
PostHog/skills · skills/omnibus/instrument-feature-flags · commit a5d30e7
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by PostHog or PostHog.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download instrument-feature-flags.zip