Audit PostHog experiments and feature flags for configuration issues, staleness, and best-practice violations. Read when the user asks to audit, health-check, or review experiments or feature flags, check flag hygiene, or verify experiment setup.
This skill teaches you how to run configuration audits on experiments and feature flags.
All checks use read_data and list_data — no SQL queries are needed for Phase 1 checks.
When the user asks about a specific experiment or flag:
read_data (e.g., read_data("experiments", id) or read_data("feature_flags", id)).[Experiment: name](/experiments/id) or [Flag: key](/feature_flags/id).When the user asks to audit all experiments or all flags:
list_data (e.g., list_data("experiments") or list_data("feature_flags")).When the user asks for a comprehensive audit of both experiments and flags:
list_data("experiments") and all flags via list_data("feature_flags").create_notebook for easier navigation. Otherwise report inline.For each finding, include:
🔴 CRITICAL, 🟡 WARNING, or 🔵 INFOExample:
🟡 WARNING — Flag integration · Experiment: checkout-redesign The linked feature flag is inactive (paused). Traffic is not being split. Action: Re-enable the flag or end the experiment.
Some checks require activity logs, which may not be available via read_data.
If activity log data is unavailable:
checkActivityHistory (experiment check) entirely.Skipped: Activity history checks (activity logs not available via current tools)
If a read_data or list_data call fails for some entities: