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.
76
96%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
This skill teaches you how to run configuration audits on experiments and feature flags.
All checks use the experiment and feature flag read tools (experiment-get, experiment-list, feature-flag-get-definition, feature-flag-get-all) — no SQL queries are needed for Phase 1 checks.
When the user asks about a specific experiment or flag:
experiment-get (experiment ID) or feature-flag-get-definition (numeric flag ID).[Experiment: name](/experiments/id) or [Flag: key](/feature_flags/id).When the user asks to audit all experiments or all flags:
experiment-list or feature-flag-get-all.When the user asks for a comprehensive audit of both experiments and flags:
experiment-list and all flags via feature-flag-get-all.notebooks-create 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 (feature-flags-activity-retrieve for flags), which may not be available in every session.
If activity log data is unavailable:
checkActivityHistory (experiment check) entirely.Skipped: Activity history checks (activity logs not available via current tools)
If a fetch call fails for some entities:
bb04e92
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.