posthog/instrument-feature-flags
skills/instrument-feature-flags/SKILL.md
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.
$ install --global
skillsauthnpx skillsauth add posthog/ai-plugin instrument-feature-flagsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 6, 2026, 6:08 AM120.8s24 files scanned
SKILL.md
- name:
- instrument-feature-flags
- description:
- >-
- author:
- 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 API key is missing, use the PostHog MCP server's
projects-gettool to retrieve the project'sapi_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 API key instead. - For the PostHog host URL, use
https://us.i.posthog.comfor US Cloud orhttps://eu.i.posthog.comfor EU 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 - docsreferences/react-native.md- React native feature flags installation - docsreferences/web.md- Web feature flags installation - docsreferences/nodejs.md- Node.js feature flags installation - docsreferences/python.md- Python feature flags installation - docsreferences/django.md- Django - docsreferences/flask.md- Flask - docsreferences/php.md- Php feature flags installation - docsreferences/laravel.md- Laravel - docsreferences/ruby.md- Ruby feature flags installation - docsreferences/ruby-on-rails.md- Ruby on rails - docsreferences/go.md- Go feature flags installation - docsreferences/java.md- Java feature flags installation - docsreferences/rust.md- Rust feature flags installation - docsreferences/dotnet.md- .net feature flags installation - docsreferences/dotnet.md- .net - docsreferences/elixir.md- Elixir feature flags installation - docsreferences/android.md- Android feature flags installation - docsreferences/ios.md- Ios feature flags installation - docsreferences/usage.md- Ios SDK usage - docsreferences/flutter.md- Flutter feature flags installation - docsreferences/api.md- API feature flags installation - docsreferences/next-js.md- Next.js - docsreferences/adding-feature-flag-code.md- Adding feature flag code - docsreferences/best-practices.md- Best practices for production-ready flags - docs
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.
Related Skills
posthog/signals-scout-web-analytics
tools
VerifiedTrustedCommunity
Focused Signals scout for PostHog projects with web traffic. Watches the acquisition and site-health layer the web analytics product reports on: per-channel session volume diverging from the site's own rhythm (an acquisition source silently collapsing or surging), attribution breakage (paid/campaign traffic reclassifying into Direct or Unknown when tagging breaks), landing pages that break (bounce-rate steps, 404 spikes, entry-path cliffs), and page-performance regressions (web vitals p75 steps). Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet.
51SKILL.mdUpdated Jun 11, 2026
posthog/signals-scout-session-replay
tools
VerifiedTrustedCommunity
Focused Signals scout for PostHog projects using session replay. Watches two promises the replay product makes: that sessions are actually being recorded (capture integrity — recording volume vanishing while site traffic doesn't), and that the friction evidence inside recordings gets seen (rage-click / dead-click clusters concentrating on a page or element, error-after-interaction cohorts, recurring replay vision themes nobody aggregates). Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet.
51SKILL.mdUpdated Jun 11, 2026
posthog/signals-scout-health-checks
tools
VerifiedTrustedCommunity
Focused Signals scout for PostHog setup health. Reads the project's active health issues — the deterministic findings of PostHog's own health checks (no live events, outdated SDKs, missing reverse proxy, absent web vitals, ingestion warnings, failing data-warehouse models, and more) — and decides which are genuinely worth surfacing. Unlike a one-signal-per-issue push, it bundles kind-clusters into a single finding, weights by real blast radius (cross-referencing actual event volume and reach), and prioritizes issues an agent can resolve via the MCP. Emits only above the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet — no dependencies on other skills.
51SKILL.mdUpdated Jun 11, 2026
posthog/signals-scout-feature-flags
tools
VerifiedTrustedCommunity
Focused Signals scout for PostHog projects using feature flags. Watches the flag roster and the `$feature_flag_called` evaluation stream for contradictions between a flag's configured state and its real traffic: evaluation cliffs on healthy flags, ghost flags (code calling keys that no longer exist), response-distribution shifts with no corresponding flag edit, and flag debt (stale, fully-rolled-out, or dead flags still burning evaluations). Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet — no dependencies on other skills.
51SKILL.mdUpdated Jun 11, 2026