REPO PACKAGE
posthog skills
COMMUNITY170skills
5ready to use
LABSCO SUMMARY
A large share is one skill per SDK or platform repeated across a category: fifteen separate error-tracking skills (Android, Angular, Flutter, Go, Hono, Next.js, Node, Nuxt, Python, React, React Native, Ruby, Ruby on Rails, Svelte, Web), a similar spread of feature-flag and framework-integration skills, and a smaller set of log-shipping and combined-instrumentation skills. The rest cover PostHog's actual product surface directly — authoring and diagnosing experiments, feature flags, session replay, LLM analytics, its HogQL-backed endpoint layer, and its newer Signals anomaly-scout tooling.
This is for a team already running PostHog that works in an MCP-capable client; the mcp_service-classified majority assume you've connected PostHog's own MCP server to a real project, and the rest expect API credentials directly. Either way there is no working demo mode. Only five skills need nothing at all: two formatting or reference notes, a monthly-to-annual conversion helper, an incremental-sync tuning guide, and a user-interview planning skill.
READ THE FULL ANALYSIS
Some of the 176 are PostHog's own internal tooling, not yours. account-handover drafts notes for one PostHog TAM or CSM handing an account to another; posthog-inbound-leads, posthog-onboarding-lead-research, posthog-pls-big-fish, and posthog-pls-transition-leads all triage and research PostHog's own sales pipeline in Salesforce. These are real, working skills — just not ones an outside team installing this repository would ever run.
License. MIT, stated in the README and matching what we recorded for the skills themselves.
ALSO IN THIS PACKAGE
PLUGINS
6 itemsPLUGIN
impersonation-toolkit
Run impersonation-scoped audits against a customer's PostHog project via Claude Code + the PostHog MCP plugin. Audits are read-only, enforced server-side by PostHog's read-only impersonation.
PLUGIN
posthog-debugger
Debug and inspect PostHog implementations on any website
PLUGIN
posthog-survey-creator
Create and configure surveys in PostHog through guided conversation
PLUGIN
posthog-inbound-lead
Evaluate and respond to inbound PostHog sales leads from Salesforce
PLUGIN
posthog-pls-big-fish
Research, qualify, and suggest outreach for PostHog big fish product-led leads
PLUGIN
posthog-customer-deep-dive
Research a PostHog customer account, then draft an outreach email, a reply, or a full call-prep brief with a notebook prompt
WHAT'S INSIDE
170 showing · 170 totalReady to use
Nothing else to set up — install it and go.
170 of 170
SETUP
Showing all 170 skills
account-handover
When a customer account changes hands, this writes the briefing for whoever picks it up, and marks the gaps only the departing manager can fill.
analyzing-experiment-session-replays
Screen recordings of real visitors, sorted by which version of an A/B test they were shown, so a winning or losing result can be watched rather than only measured.
assessing-heatmaps
A read of how visitors actually use one web page — what they click, where they get stuck, how far down they ever scroll — and what to change because of it.
auditing-endpoints
An Endpoint in PostHog is a saved query that other software can call — this is the sweep that finds the ones worth switching off, and it only reports; it never switches anything off itself.
auditing-experiments-flags
An inspection of a project's feature flags, the on/off switches that decide who sees what, and of the A/B tests built on them: what is misconfigured or stale, worst first, with the fix named.
authoring-log-alerts
Setting up an alarm on your server logs so it goes off a few times a week, not every hour and not never, by measuring how the service actually behaves first.
cleaning-up-stale-feature-flags
Old feature switches pile up long after everyone already sees the new thing; this finds the ones nobody checks any more and strips them out of the code first, leaving the switch itself for later.
configuring-experiment-analytics
An A/B test result only means something if the right people are counted and the right outcome is measured. This is where both get set.
configuring-experiment-rollout
Who sees the new version, and how much of the audience is let into the test at all — the two percentages behind every A/B test, and what each one is actually for.
consuming-endpoints-from-client-code
A mobile app or a customer dashboard needs numbers that live in PostHog — this is the work at that end: shaping the request, carrying a key that is allowed to ask, and making sense of the refusals.
copying-flags-across-projects
The same feature switch, recreated in another PostHog project — staging to production, say — arriving switched off until someone decides otherwise.
creating-ai-subscription
Ask a question in plain English once, and get a freshly written answer in email or Slack every morning, week or month — composed from current data each time, not a copy of a saved chart.
creating-an-endpoint
Publishing a PostHog query so other software can call it for data — and the handful of choices made at that moment that decide whether it stays fast and cheap, or doesn't.
creating-experiments
Setting up an A/B test in PostHog comes down to three answers: what you expect to happen, who ends up in the test, and what number will settle it.
creating-replay-vision-scanners
Set an AI to watch every new session recording as it arrives, and size it before switching it on — one with too wide a net starts spending real money on its first sweep.
designing-email-templates
Composes an email's design as editable blocks with personalized text, saves it as a reusable PostHog template, and keeps it in sync with the visual editor on every later edit.
diagnosing-ci-and-merge-bottlenecks
Code changes wait in a queue before they ship — this finds where they actually wait: a slow automated check, a review nobody picked up, or one job that keeps failing at random.
diagnosing-endpoint-performance
Slow, timing out, or eating the cost cap — the three complaints one published PostHog query can produce, and the fixed order in which to work through the remedies.
diagnosing-experiment-results
An experiment showing zero results, or a winner that can't be real, usually has a known cause. This sorts through them and names only the ones the evidence actually supports.
diagnosing-failed-warehouse-syncs
Resyncing from scratch is almost never the right first move when data stops arriving from Stripe, a database or another outside system — this is the order to check things in instead.
diagnosing-missing-recordings
A session has no replay of what the visitor did; this is the walk through the reasons recording can silently fail to start.
diagnosing-sdk-health
Which bits of PostHog's tracking code in your apps have fallen behind, why each one was flagged, and — when the code is to hand — the upgrade made for you.
diagnosing-stacktrace-symbolication
Released apps ship their code compressed and renamed, so crash reports arrive unreadable; when the translation back to real file and line names fails, this is where the break is found.
downloading-batch-export-files
A one-off dump of your PostHog data as a file you can download, rather than a standing pipeline that keeps shipping it somewhere else.
error-tracking-android
Every crash in an Android app ends up in PostHog, set up once at launch so it is already watching before the first screen appears.
error-tracking-angular
Error reporting for an Angular app, added the way Angular expects it: one shared service the rest of the app asks for, and the keys kept out in the environment files.
error-tracking-flutter
A Flutter app can report its crashes to PostHog by itself; this covers switching that on, and the handful of spots where you still have to catch an error by hand.
error-tracking-go
Wiring PostHog's error reporting into a Go application, alongside the error handling that is already there rather than in place of it.
error-tracking-hono
Hono servers can hand their unhandled errors to PostHog; this adds it next to the error handling already there rather than replacing it.
error-tracking-nextjs
Errors from a Next.js app land in PostHog, set up in the file Next.js already runs on the client, with tracking calls placed where the user actually clicked.
error-tracking-node
On a Node.js server the browser package is the wrong one; this wires the server-side one into the app's error handler and tunes sending for how long the process lives.
error-tracking-nuxt
PostHog can catch a Nuxt app's exceptions on its own once it is switched on; the rest is adding calls by hand where an error would otherwise slip past.
error-tracking-python
Python scripts lose every event they collected if they exit without shutting the client down — this covers that, switching on automatic error capture, and keeping personal data out of events.
error-tracking-react
Error tracking for a React app, plus a short discipline on where PostHog calls belong in a component — much of this doc is about what not to put in an effect.
error-tracking-react-native
A React Native app reporting crashes to PostHog, with the project key baked in at build time and the PostHog wrapper placed where the navigation library needs it.
error-tracking-ruby
Crash reporting from Ruby, past the two traps that sink most attempts: the require line doesn't match the gem name, and exiting without shutting the client down loses every event.
error-tracking-ruby-on-rails
Three things go to PostHog from a Rails app: exceptions nobody caught, the ones Rails caught quietly itself, and background jobs that failed — each tagged with the user it happened to.
error-tracking-svelte
One setting in a SvelteKit config file silently breaks session replay when pages render on the server; this gets error reporting in without tripping over it.
error-tracking-web
Catching errors in a plain browser app, and the discipline that comes with it: names and emails belong on the person's record, never on the events themselves.
experiment-audit
Somebody's A/B test isn't giving the answer they expected. This checks the four places it usually goes wrong, and refuses to guess when it can't reach their real data.
exploring-apm-traces
A single web request passes through a chain of services before it answers; this follows the chain to find which link was slow, which one failed, and when it started.
exploring-autocapture-events
PostHog records every click on a page without being told to; this is how you get from that pile to one named thing — this button, this link — that you can count and chart.
exploring-endpoint-execution-logs
Every time a published PostHog query runs it leaves one line behind saying how it went; this reads those lines back to answer what happened the last time it ran.
exploring-live-traffic
Who is on the site this minute, what they are looking at, and which bots are crawling it — the last half hour only, with a way to stretch any of it into a longer chart.
exploring-llm-clusters
PostHog groups similar AI requests together and gives each group a name; this skill reads those groups back, so thousands of individual requests become a short list you can compare and dig into.
exploring-llm-costs
Every call your product makes to an AI model arrives in PostHog with a price on it; this skill adds those prices up, so the AI bill stops being one lump sum nobody can explain.
exploring-llm-evaluations
Something is already scoring your AI's answers automatically — a rule, a second AI acting as judge, or the mood of the user's reply. This skill looks behind those scores: which answers failed, what the grader said, and whether the grader itself is wrong.
exploring-llm-traces
Reads a PostHog AI trace or session — the tree of tool calls, model calls, and their inputs and outputs — so you can see exactly what an AI agent did and why, without leaving the conversation.
feature-flags-android
Hide a new Android feature behind a switch you control from PostHog, so it can go on for a few users or off entirely without shipping an update — the work here is adding that switch to code you already have.
feature-flags-api
A service can ask PostHog, before it answers a request, whether a given feature is switched on for this particular user — so a change can go out to a slice of traffic and be pulled back without a deploy. This adds that question to an API codebase you already have.
feature-flags-dotnet
In a .NET codebase, a feature can be put behind a switch that lives in PostHog rather than in the code, so turning it on for some people and off for others stops needing a release.
feature-flags-elixir
Shipping a change and switching it on become two separate decisions: PostHog holds the switch, and the Elixir code simply asks whether it is on before running the new path.
feature-flags-flutter
A Flutter app can check with PostHog before it shows something, so a new screen reaches only the people you picked and disappears again the moment you change your mind — no new build required.
feature-flags-go
Put a Go service's new behaviour behind an on/off switch that lives in PostHog, so it can be enabled for a few users first and cut off instantly if it misbehaves.
feature-flags-ios
An iOS feature can ship switched off and be turned on later from PostHog for whoever you choose — getting there is partly flag checks in your Swift code, partly Xcode plumbing.
feature-flags-java
Deciding who gets a new feature moves out of the Java code and into PostHog, where you can change your mind at any time without another release.
feature-flags-nextjs
A Next.js page runs partly on the server and partly in the browser, and a feature switch has to be read correctly in both — this sorts out which side asks PostHog where, so a visitor never sees the wrong version flash up first.
feature-flags-nodejs
Before a Node.js server responds, it can check with PostHog whether a feature is on for this particular person — which is what lets a change reach one percent of users instead of everyone at once.
feature-flags-php
A PHP application can ask PostHog whether a feature is on for the current user instead of hard-coding who gets it; this adds those checks, together with the one-time setup the PHP library expects.
feature-flags-python
Python code that asks PostHog whether a feature is switched on for the person in front of it, dropped in next to what is already there rather than replacing it.
feature-flags-react
A React component can ask PostHog whether a feature is on for this visitor before deciding what to show; this adds that check the way the PostHog library expects, and tidies up some common React habits in the code it touches.
feature-flags-react-native
A React Native app can check with PostHog before showing a new feature, so you choose who sees it; the mobile catch is that the PostHog keys are baked in when the app is built, so they have to come from a file rather than the running environment.
feature-flags-ruby
Ruby code gains the ability to ask PostHog whether a feature is on for a given user — written the way the PostHog gem actually wants it, which is not always the way you would guess.
feature-flags-rust
A Rust service asks PostHog, rather than its own config file, whether this request should get the new behaviour — so it can be switched on for a few people and switched off again without rebuilding anything.
feature-flags-web
A visitor to your site sees a new feature, or does not, depending on a switch you keep in PostHog — this adds the check to the page's JavaScript, settling it on the server where it can so nothing flashes.
feature-usage-feed
Every time somebody uses one of your AI features, a second AI reads what happened and writes a single line saying what that person was trying to do, then posts it into Slack as it happens.
finding-deleted-feature-flags
Finds which feature flags were deleted in a project within a recent time window, and who deleted each one and when, by cross-referencing the per-flag activity log since the deletion time isn't exposed anywhere else.
finding-experiments
People refer to an experiment by a half-remembered name, or as the one from last week, while PostHog's other tools need its ID — this bridges that gap, and asks which was meant when several fit.
finding-replay-for-issue
Given an error tracking issue, finds and ranks the session recordings linked to it, and surfaces the one that best shows what the user was doing right before the error, instead of guessing from potentially hundreds of clips.
finding-sessions-to-watch
Turns a vague goal, like understanding why people drop off at checkout, into a short, high-signal shortlist of session recordings worth watching, instead of dumping the full unfiltered list.
formatting-insight-axes
Picks the right unit formatting, such as duration, currency, or percentage, for a chart's y-axis when building or editing a PostHog insight, instead of faking units by dividing the underlying data.
grouping-noisy-errors
Consolidates PostHog error issues that are really the same bug reported under different fingerprints, merging the duplicates and, when the noise keeps recurring, adding a rule so future events stop splitting into new issues.
inbox-exploration
Explores PostHog's Inbox, where error, replay, and analytics signals cluster into reports, and lets the user triage, drill into, or act on what it surfaces, including turning a report into a pull request.
instrument-error-tracking
When your app crashes, this makes sure PostHog hears about it — the crash is recorded automatically, and the report points at the real line of your code rather than a pile of compiled output.
instrument-feature-flags
Releasing a new feature stops being all-or-nothing: it goes out switched off, and you turn it on for the people you choose, when you choose.
instrument-integration
A project that has never sent PostHog anything gets the connection made — the right library for whatever the project is built with, installed and switched on, so events can start flowing.
instrument-llm-analytics
Once a product starts calling an AI model, nobody can see what those calls cost or how long they take; this wires them up so every one of them is recorded in PostHog, whichever provider is behind it.
instrument-logs
The lines an application writes as it runs stop staying on the server and start arriving in PostHog — and new code is written to log in a form you can search, rather than as loose sentences.
instrument-product-analytics
Instead of recording every click, this goes after the dozen or so moments that actually matter — signing up, paying, giving up halfway — so the numbers you end up with are worth reading.
integration-android
An Android app that currently tells you nothing about how it is used starts reporting to PostHog, set up once when the app launches so every screen is covered without visiting each one.
integration-angular
Wire an Angular app up to PostHog so you can see what people actually do in it, following Angular's own conventions rather than a generic drop-in setup.
integration-astro-hybrid
Astro sites can mix pages built ahead of time with pages built fresh for each visitor, and tracking has to be wired differently for each — this covers the mixed case, so data comes in from both kinds.
integration-astro-ssr
On an Astro site where every page is built by the server as it is asked for, what a visitor does can be recorded from the browser and from the server at once — this sets up both halves so they add up to one picture.
integration-astro-static
Nothing on a fully static Astro site runs on a server, so everything you learn about a visitor has to be gathered in their browser — this puts that gathering in once, for every page.
integration-astro-view-transitions
When an Astro site swaps pages smoothly instead of reloading the browser, the usual page-view counting quietly stops working after the first page; this is the fix, so every page a visitor moves through still gets counted.
integration-django
A Django site starts recording what people do, hooked in at the point every request already passes through — and with a firm rule about never putting somebody's email or name into the record.
integration-expo
An Expo app starts reporting what people do in it, with the two things that catch everyone out handled: where Expo expects the PostHog key to live, and the fact that moving between screens is not counted for you.
integration-fastapi
Every request a FastAPI service handles can leave a record in PostHog; the trick is starting and stopping the connection in step with the service itself, so nothing is still sitting in a queue when the process ends.
integration-flask
Flask catches its own errors, which means nothing reaches PostHog unless you report it on purpose — so this sets PostHog up once when the app is created, and puts those deliberate reports in.
integration-javascript_node
Server-side Node.js code gets the ability to record what it did, handled differently depending on whether it is a server that stays up or a script that exits in a second — which is where events usually go missing.
integration-javascript_web
A JavaScript app running in someone's browser starts sending PostHog a record of what they do: clicks and page views picked up on their own, and the visit tied to the right account once they log in.
integration-laravel
A Laravel app starts telling PostHog what its users do, with all of it going through a single place in the code — so a year later you still know where the tracking lives.
integration-nextjs-app-router
A Next.js project on the newer App Router starts sending PostHog what people do in it, with each recording placed where the action happens — on the button that was clicked, not in code that notices afterwards that something changed.
integration-nextjs-pages-router
Older Next.js projects, the ones still on the Pages Router, get the same treatment: PostHog wired in so a recorded event sits next to the thing it measures, instead of chasing a change that has already happened.
integration-nuxt-3.6
A Nuxt app anywhere in the 3.0 to 3.6 range goes from measuring nothing to recording what visitors do, knowing who they are, and reporting its own errors — a short setup, taken in order.
integration-nuxt-4
By the end, a Nuxt 4 site records what visitors do, knows who they are once they sign in, and reports its own errors to PostHog; this is the short list of steps that gets it there.
integration-python
Recording what a Python program did, and for whom, built on a client you create explicitly rather than a global setting — and with strict rules about what must never end up in a record.
integration-react-native
On mobile the PostHog key is baked in when the app is built, and the tracking has to sit in the right place relative to navigation — get those two right and a React Native app reports what people tap and where they go.
integration-react-react-router-6
In a React app on React Router v6, an event belongs to the click or submit that caused it — this wires PostHog in that way, rather than into code that reacts to the change afterwards.
integration-react-react-router-7-data
React Router v7 can be set up three different ways, and this is the one for data mode, where the routes are declared in code — PostHog goes in so an event is recorded by the thing that caused it.
integration-react-react-router-7-declarative
Some React Router v7 projects still write their routes as plain components, the way earlier versions did; this is the PostHog setup for those, with an event recorded by the click or submit behind it.
integration-react-react-router-7-framework
Framework mode is React Router v7 running as a full-stack framework, with its routes taken from the file layout — PostHog is set up for that shape, capturing an event where it happens rather than noticing it later.
integration-react-tanstack-router-code-based
When a React app moves between pages without reloading, nobody counts the page views unless you ask the router for them — this covers TanStack Router with its routes written in code, and puts that counting in.
integration-react-tanstack-router-file-based
A React app whose pages are laid out as files and routed by TanStack Router never reloads, so the browser will not count page views for you; here they come off the router's own navigation instead.
integration-react-vite
A plain React app built with Vite, with no router in it at all: PostHog goes in so a recorded event sits in the click or submit handler that caused it, which is where React itself says it belongs.
integration-ruby
A short-lived Ruby script throws away everything it has queued unless it is told to shut the client down — that, along with event capture and identifying who did what, is what this sets up.
integration-ruby-on-rails
A Rails app can report its own crashes and failed background jobs to PostHog without anybody adding a line to each controller, because a Rails-specific package does it on top of the plain Ruby one.
integration-sveltekit
Wires a SvelteKit site up to PostHog so you can see what visitors do on it, including the one setting people usually miss that quietly breaks visit recordings.
integration-swift
Gets PostHog analytics into a native iPhone or Mac app, Xcode wiring and all — the dependency, the key handling, and the version checks that people usually get wrong by hand.
integration-tanstack-start
A TanStack Start app runs partly in the browser and partly on the server, and this sets PostHog up correctly on both halves rather than only the one you can see.
integration-vue-3
Adds PostHog analytics to a Vue 3 app, taking it through a short numbered setup that ends with events being captured, users identified, and errors tracked.
investigate-metric
A number on one of your PostHog charts moved and nobody knows why — this works through it the way an analyst would and writes up the likeliest cause, how sure it is, and what to do next.
investigating-error-issue
Everything known about one error in your app, pulled together in a single pass instead of six separate lookups — what it is, how often it happens, and who it is happening to.
investigating-replay
A session recording is a video of one person using your site, and this pulls together the story behind it — who they were, what they did, and what went wrong for them.
llm-analytics-setup
Adds a few lines to an app that already calls an AI model, so every call turns up in PostHog with the model it used, how long it took and what it cost — with a ready-made recipe for over thirty providers and frameworks.
logs-datadog
An app that already collects its logs with Datadog gets PostHog added as a second place those logs land.
logs-go
Sends a Go service's log lines — its running record of what it did and what went wrong — over to PostHog.
logs-java
A Java app keeps logging exactly where it logs today, and a copy of every line goes to PostHog as well.
logs-nextjs
Next.js writes plenty to its logs when something goes wrong; this puts those logs into PostHog with the rest of the app's data.
logs-nodejs
Gets a Node.js app's logs into PostHog as structured records with named fields, instead of lines of plain text.
logs-other
For an app in a language PostHog does not have its own logging guide for, this is the fallback route for getting its logs across.
logs-python
Puts a Python app's logs into PostHog, and carries the rules for using PostHog's Python library safely alongside them.
managing-endpoint-versions
Every edit to the saved query behind a PostHog data endpoint stacks a new version on top, and there is no way to point callers back at an older one — this is how to work with that.
managing-experiment-lifecycle
An A/B test in PostHog goes through stages — starting, pausing, finishing, shipping the winner, putting it away — and this is how to move it between them without wrecking the results you already have.
managing-path-cleaning-rules
Turns URLs that only differ by an ID, slug, or date — like /users/123 and /users/456 — into one grouped row in PostHog's analytics, by inspecting real traffic and writing, testing, and applying path cleaning rules.
managing-subscriptions
Sets up scheduled email, Slack, or webhook deliveries of a PostHog dashboard or insight snapshot, and can attach an AI-written summary to each one.
monthly-to-annual
For a PostHog sales rep, builds the case for moving one named monthly-paying customer onto an annual prepaid plan — pulling their billing history, checking recent support and sales signals for any reason to hold off, running the discount math, and drafting a Slack message in the rep's own voice.
omnibus-instrument-error-tracking
When the app breaks for somebody, nobody hears about it unless something is watching — this walks the codebase and sets that watching up, whatever language or framework it is written in.
omnibus-instrument-feature-flags
A feature flag is an on/off switch around new code, so it can be turned on for a few people before everyone — this creates one and wires it into the code for you.
omnibus-instrument-integration
Nothing else PostHog does works until the app is actually sending it data — this is the first-time setup that gets the package in and started the way the project's own framework wants it.
omnibus-instrument-llm-analytics
Goes looking through a codebase for every call it makes to an AI model and puts a meter on each one — including in a project where PostHog has not been set up at all yet.
omnibus-instrument-logs
Works out for itself how the code already writes its logs, then routes a copy of them to PostHog — including the plumbing, when the project has none yet.
omnibus-instrument-product-analytics
Scans a codebase for the moments that matter to the business — signing up, paying, checking out — and adds the few lines that record each one as it happens.
posthog-debugger
Opens a live website in a browser and inspects how PostHog is actually configured on it — installed or not, which features are on, what network traffic it's sending — without changing anything on the page.
posthog-inbound-leads
Someone has written in asking about PostHog — this works out who they are and what they actually need, then drafts the reply that fits.
posthog-onboarding
A customer already has PostHog installed but is getting little out of it — this works out what is missing from their setup and hands back a staged plan for fixing it.
posthog-onboarding-lead-research
The onboarding team hands a self-serve account over to sales, and this is the research brief that comes back: who the company is, where it is heading, and whether it is worth a rep's time yet.
posthog-pls-big-fish
A big company has quietly signed itself up to PostHog's free tier and nobody asked them to — this works out whether anyone is really using it, and whether it is worth a rep getting in touch.
posthog-pls-transition-leads
Investigates a PostHog customer approaching a billing transition — expiring startup credits or a first invoice over $2,000 — then recommends whether to reach out and drafts the email if so.
posthog-survey-creator
Walks a product manager through building a PostHog survey by conversation — picking a template like NPS or CSAT, targeting the right users, and setting how often it shows — then saves it as a draft to review before launch.
querying-posthog-data
Before anyone writes a query against their PostHog data by hand, this says where everything is kept and gives worked examples to start from — and stops them inventing their own definition of a number the company has already agreed one for.
setting-up-a-data-warehouse-source
Connects an external service, like Stripe or Postgres, to PostHog's data warehouse — validating credentials, discovering tables, and choosing how each one should sync — so its data can be queried alongside PostHog's own.
signals
A signal is one automated note that something looks off — 'error rate tripled on checkout' — and this is how to dig through them directly, underneath the tidy reports they get bundled into.
signals-scout-ai-observability
An automatic check on what a team's AI features cost, how fast they answer and how often they fail; it only writes something up when the change it found is real and worth someone's time.
signals-scout-anomaly-detection
Teams put numbers on dashboards and then stop looking at them; this keeps checking the ones they do look at against their own normal week, and speaks up when one spikes, drops or flattens out.
signals-scout-csp-violations
A site's security rules tell the browser which scripts it may load; every time one gets blocked a report comes in, and this picks the handful of blocks that mean something is wrong out of that flood.
signals-scout-data-pipelines
PostHog can be set up to forward data on to other places, and when that forwarding dies nothing looks broken — the site is fine, the dashboards are green. This is the check that notices anyway.
signals-scout-error-tracking
Some errors are always firing, so the useful question is which ones are new, which are getting worse and which of them share a single cause — this goes through them run after run to answer it.
signals-scout-experiments
Checks the measurement machinery under a team's A/B tests rather than the results, because a test whose data has quietly gone wrong will still hand the team a confident answer.
signals-scout-feature-flags
Feature flags pile up, and over time they stop matching what the code is really doing — this compares every flag against the calls actually arriving from the running app.
signals-scout-general
The catch-all Signals scout: it explores whatever part of a PostHog project the specialist scouts aren't already covering, looking for cross-product patterns worth surfacing as a report.
signals-scout-health-checks
Reads the active issues from PostHog's own scheduled health checks and decides which ones are actually worth a person's attention, bundling repeats of the same problem into one report instead of filing dozens.
signals-scout-inbox-validation
Follows up on reports that PostHog's inbox marked resolved after a fix merged, and re-measures the underlying problem to check whether the fix actually held.
signals-scout-logs
Nobody reads the thousands of log lines an app writes every hour; this compares what it is writing now against what it was writing before, and points only at what changed.
signals-scout-observability-gaps
Looks for meaningful gaps between the events a team is actually producing and what they've set up to watch, then recommends a specific insight, dashboard, or alert to fill it.
signals-scout-replay-vision
An AI is set loose on a team's session recordings to judge them one at a time; this steps back to look across all of them, and checks the watcher itself has not quietly stopped watching.
signals-scout-revenue-analytics
Revenue numbers in PostHog are pieced together from Stripe and from the app's own events, so when either stops arriving the dashboard keeps showing a figure that is simply wrong. This watches the plumbing, not the figure.
signals-scout-session-replay
Session recordings are only worth anything if they are actually being captured and if somebody spots the pattern in them — this checks both: that recording has not quietly stopped, and that users are not all getting stuck in the same place.
signals-scout-surveys
Survey answers pile up unread — this reads them, clusters what people are actually saying into recurring themes, and keeps an eye on the scores and response rates while it is there.
signals-scout-web-analytics
A site's total traffic can look perfectly normal while one source of it has collapsed — this reads the traffic one channel and one landing page at a time, so the average stops hiding the break.
skills-store
Discovers, loads, and manages a team's shared agent skills stored inside PostHog itself, so a team can reuse a workflow instead of re-teaching an agent the same steps every time.
suggesting-data-imports
Recognizes when the data a user wants — revenue, CRM deals, support tickets, a production database table — lives outside PostHog, then points them to the right data warehouse source to import it.
suppressing-noisy-errors
Finds error patterns in PostHog's error tracking that are worth silencing, then creates a narrowly scoped rule to drop just those events at capture time without losing real bugs along with them.
tools-and-features-hogql
Teaches how to write HogQL, PostHog's SQL dialect for querying its events, people and sessions, using the patterns and functions PostHog's dashboards expect.
triaging-error-issues
Turns PostHog's list of active error-tracking issues into a short, ranked review for a daily or on-call check, with a suggested next action for each one.
triaging-visual-review-runs
Before a code change can merge, PostHog screenshots the interface and compares it against the last approved version — this reads those before-and-after pictures itself instead of trusting the percentage next to them.
tuning-incremental-sync-config
Changes how an existing PostHog data-warehouse table syncs — for example switching it from a full reload to incremental updates, or fixing its primary key or schedule — and works out whether the already-synced data needs to be wiped and reimported afterward.
user-deep-dive
Builds a profile of how one PostHog user actually uses the product — what they do, which pages they spend time on, and how engaged they are — by combining PostHog's own event data with their account record, ready to brief someone before a customer call.
working-with-skills
Shows how to use PostHog's tools for creating, reading, and editing shared skills efficiently — favoring small, targeted edits over full rewrites so changes stay reviewable and don't silently overwrite someone else's work.
workload-analysis
Turns a PostHog customer account's billing and CRM data into an interactive report showing how their spend splits across SDKs, products and teams, and where the account has room to expand or is at risk of shrinking.
No skill in this package matches that.
HOW TO GET IT
WHOLE PACKAGEInstall the whole package (170 skills)
npx skills add posthog/skillsSINGLE SKILLOr install a single skill
npx skills add posthog/skills --skill <name> --full-depthPick the skill name from the Skills tab — each entry there installs independently.
PLUGIN MARKETPLACEAdd the marketplace, then install the plugins you want
/plugin marketplace add posthog/skills/plugin install impersonation-toolkit@PostHog-skills/plugin install posthog-debugger@PostHog-skills/plugin install posthog-survey-creator@PostHog-skillsTyped inside the agent's own prompt, not in a terminal. The marketplace lists 6 plugins; three are shown. Every one installs the same way, with its own name before @PostHog-skills.