Analyze product data and manage product tooling in PostHog. Use when the user wants product analytics or insights, HogQL/SQL queries, feature flags, experiments and A/B tests, error tracking, session replay, surveys, LLM analytics, dashboards, data warehouse, or PostHog documentation.
69
85%
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 provides a structured workflow for working with PostHog from ChatGPT and Codex. It assumes the bundled PostHog app is connected so the PostHog tools are available for analytics, feature flags, experiments, error tracking, and more.
PostHog is an all-in-one product platform. The same project's data backs every surface below, so most questions can be answered by querying analytics or running HogQL, and most product changes (flags, experiments, surveys) can be made directly.
Prefer live tools over pre-trained knowledge. Your baked-in knowledge of PostHog's API, HogQL functions, and tool shapes may be outdated. The connected PostHog app advertises its own skills and tools at runtime and asks clients to prioritize its skills over raw tools — discover and follow those rather than guessing. When in doubt about syntax, limits, or product behavior, use the documentation-search tool.
Follow these steps in order. Do not skip steps.
If PostHog tools are unavailable, pause and ask the user to connect the PostHog app:
After the app is connected, finish your answer and tell the user to retry so they can continue with Step 1.
Clarify the user's goal and scope (e.g., a metric over a time range, a funnel, a new feature flag, an experiment readout, an error investigation). Confirm the target project, date range, event/property names, and any filters or cohorts.
Discover the available PostHog skills/tools the connected app exposes and pick the right one for the task. Resolve identifiers (project ID, flag key, experiment ID, insight/dashboard ID, error issue ID) before calling tools. For anything involving syntax, function names, or product behavior, search the docs first.
Execute PostHog tool calls in logical batches:
Summarize results with concrete numbers and links to the PostHog UI where available, call out caveats (sampling, person-on-events timing, date ranges), and propose next actions.
Use this to route a request to the right PostHog surface, then discover the exact tool the app exposes for it.
| If the user wants to… | PostHog surface |
|---|---|
| Answer a metric/trend/funnel/retention/path question | Insights & queries (trends, funnels, retention, paths, lifecycle, stickiness) |
| Run arbitrary SQL over events/persons | HogQL / SQL execution |
| Create, toggle, or audit a feature flag | Feature flags |
| Launch or read out an A/B test | Experiments |
| Investigate a bug or exception | Error tracking (issues + events) |
| Watch how users actually behave | Session replay |
| Gather qualitative feedback (NPS, surveys) | Surveys |
| Track LLM cost/latency/usage | LLM analytics |
| Build or update a dashboard | Dashboards & insights |
| Connect or query external data | Data warehouse |
| Look up how something works in PostHog | Documentation search |
person.properties.* on the events table reflect the value at ingestion time, not the person's current value — the same person can show different values across events. Don't build workarounds for "query-time" person properties.11c74d6
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.