building-canvases
Builds a small custom page or app that lives inside PostHog — a team board, a form, a written report, a little tool — and publishes it to the right team channel so others can open it.
LABSCO SUMMARY
Summary
PostHog's own plugin bundles 161 skills spanning almost the whole product, and all but a handful require a live, connected PostHog account before they do anything.
The coverage is genuinely broad: authoring and auditing feature flags and experiments, building and diagnosing workflows and email templates, exploring session replay and heatmaps, tracking LLM cost and evaluations, endpoint creation and performance triage, data-warehouse sync health, error-tracking alerts, and survey debugging across five SDKs. Most skill names read as a verb plus a PostHog surface — auditing-endpoints, diagnosing-failed-warehouse-syncs, configuring-experiment-rollout — and each activates automatically when a request matches its description rather than needing to be invoked by name.
This is for a team already running PostHog who wants their coding agent to operate the product directly: create a flag, audit stale experiments, or pull LLM spend by model, all through the MCP connection. It is not useful to anyone who doesn't have a PostHog project, and the README's own install steps (OAuth via /mcp, or a self-hosted POSTHOG_MCP_URL) are a prerequisite for the majority of what's here, not an afterthought.
READ MORE
Not every skill here is for a customer.
A few are written for PostHog's own engineers, not for someone using the product: checking-deploy-timing says outright it answers when "PostHog staff" ask if a change reached a region.
The README undercounts the package.
It describes "27+ PostHog tools" and says the plugin "also ships 30+ task-specific skills" — true as a lower bound, but the repository ships 161 skills, more than five times that figure, so the README reads as stale rather than descriptive of what installing this actually gets you.
WHAT'S INSIDE
Skills
153 of 153
SETUP
Showing all 153 skills
Canvases and small apps8 skills
building-html-canvases
Some pages you build inside PostHog are documents or pictures rather than apps — a written report, a diagram, an animated graphic, a 3D scene. This builds those as plain web pages that follow the viewer's light or dark theme.
building-react-quill-canvases
The app-style pages you build inside PostHog — live dashboards, website traffic boards, explorers, team checklists — made to look and behave like the rest of PostHog. Each card loads on its own and shows a plain error when its data fails, instead of a misleading zero.
composing-grid-canvases
Arranges a page in PostHog made of small widgets, such as your personal home page, reusing a widget that already exists before anyone builds a new one and fitting each into the box you drew for it.
managing-streamlit-apps
Runs a small interactive data app written in Python inside PostHog, where your team can open it — from first upload through new versions to switching it off. Anyone who opens the app sees data with your level of access, so publishing one means sharing that data.
querying-canvas-data
A canvas is a custom page a team builds inside PostHog, such as a status board or a task inbox; this is how its code puts real PostHog numbers on screen, with a way beside each figure to check where it came from.
validating-and-publishing-canvases
A canvas is a small custom web page that lives inside PostHog and can show your charts and data; this is how an assistant checks one for problems, saves a new version without wiping out anyone else's edits, and makes sure it actually built.
writing-streamlit-apps
Writes the code for a small interactive web page of charts, tables and sliders built on a team's PostHog data, made to run inside PostHog's own hosted sandbox and within that sandbox's fixed limits.
Flags, tests and surveys16 skills
analyzing-experiment-session-replays
Pulls session recordings for each variant in a running experiment and compares how control and test-group users actually behaved. Can also pair the recordings with a short post-flow survey for qualitative feedback on top of what was observed.
auditing-experiments-flags
A wrongly set-up experiment still produces numbers, and they are the wrong numbers. This goes through every experiment and feature flag in a project, grades what it finds worst-first, and puts a fix beside each one.
building-workflows
Something happens — a trial ends, a cart is abandoned — and a sequence of messages goes out. This builds that sequence, tests it one step at a time, changes it while it is running, and watches how it does afterwards.
cleaning-up-stale-feature-flags
Finds feature flags nobody is checking any more or that are fully rolled out, generates the exact code-cleanup instructions for each one's rollout state, then disables or deletes them only after the code is deployed.
configuring-experiment-analytics
Decides which users are counted in a PostHog experiment's results and what metric proves whether it won. Covers reusing an existing shared metric, building a new mean, funnel, ratio, or retention metric, and handling a user who saw more than one variant.
configuring-experiment-rollout
Two separate dials decide who sees what in an experiment: how many people are let into it at all, and how those inside are divided between the versions on test. This sets both, and steers you towards an even division with fewer people let in, which is the safer way to get a lopsided-looking test.
copying-flags-across-projects
Duplicates a feature flag from one PostHog project into one or more target projects in the same organization, remapping its cohort references and defaulting to landing it disabled with no scheduled changes.
creating-experiments
Start an A/B test the quick way: a name, a hypothesis, and the switch that turns it on. How the traffic gets divided and what counts as winning are settled afterwards, each by its own skill.
creating-surveys
Turns 'I want to ask users X' into a ready PostHog survey: a pop-up inside an app, an always-on feedback button, or a link you can share, shown to the right people and checked before it goes live.
debugging-experiments
For PostHog's support team: a customer says their A/B test results look wrong, and this finds which setup or tracking mistake is skewing them, proves it with the customer's own numbers, and drafts the reply with the fix.
debugging-surveys
Investigates a support ticket about a PostHog survey not appearing or its responses looking wrong, checking whether the customer's platform even supports the feature in question before concluding anything is actually broken, and helps write the reply. It is written for PostHog's support staff and works from their staff access to the customer's project.
designing-email-templates
Writes the marketing email itself — the layout, the images, the wording — and saves it into PostHog as blocks a person can still open and rearrange afterwards.
diagnosing-experiment-results
The experiment's numbers look wrong and you cannot tell whether to believe them. This walks the known ways a result goes bad and names the one that is actually happening here.
finding-deleted-feature-flags
Answers who deleted which feature flags in the last week or month, and exactly when — the deletion times are not stored where you would expect, so this goes and digs them out.
finding-experiments
People remember an A/B test by a rough name, not by its ID number; this works out which one they meant before anything gets paused, shipped or deleted.
managing-experiment-lifecycle
An A/B test moves through states — draft, running, paused, ended, shipped, archived — and each move changes who sees which version and whose data still counts; this is the guide to which move you actually want.
Modelling the data warehouse10 skills
adding-warehouse-person-properties
Takes facts that live in your own business data, like a customer's plan or yearly revenue, and stamps them onto each person or company in PostHog. From then on you can filter, segment and target by them like any built-in trait.
authoring-data-quality-checks
Sets up automatic tests on your data in PostHog, so you find out a table has gone wrong — missing IDs, duplicate rows, a sync that stopped — before anyone builds a report on it.
modeling-activation-metrics
Works out what a new user has to do in their first days to be likely to stay — tested against who actually stayed, not guessed — and then keeps count of how many new sign-ups get there.
modeling-conversion-metrics
The 'sign-up to paid' kind of number — what share of people get from one step to the next inside a set time limit — defined once so that other reports can pull the same figure instead of each counting it their own way.
modeling-dimension-tables
The small lookup lists every report leans on — country to region, plan to price tier, a calendar of dates — built once and cleanly, so each new report can join to them instead of rebuilding its own copy.
modeling-product-usage-metrics
Do people come back, how often do they show up, and are you gaining users faster than you are quietly losing them? This builds all three answers from the same stream of activity, as tables other reports can reuse.
modeling-revenue-metrics
Turns payments and subscriptions — from Stripe or from purchase events your product sends — into the revenue numbers a business runs on, such as monthly recurring revenue and revenue per customer, built on the revenue tables PostHog already keeps.
modeling-warehouse-foundations
The groundwork shared by PostHog's metric-building skills: how to write a business number down once — inside PostHog or in dbt — so every chart and dashboard uses that one version instead of working it out again.
setting-up-data-catalog
Writes down, inside a PostHog project, what each key number officially means, which of several look-alike tables to trust, and how tables link together — all as proposals a person then approves.
setting-up-warehouse-properties
Takes a table of customer details you have already brought into PostHog and copies its columns onto the matching people or company profiles, refreshed every time that table updates.
Querying what it collects33 skills
analyzing-expensive-users
Finds the users of your AI product who run up the biggest model bill and explains why — heavy volume, a pricey model, oversized prompts, long answers, or calls stuck retrying — with real example conversations as evidence.
assessing-heatmaps
Reads a page's click, rage-click, and scroll-depth heatmap, matches the hot spots to the actual elements causing them, and turns that into concrete recommendations for what to fix or move on the page.
auditing-endpoints
A clean-up review of the saved queries a project publishes for outside callers — which nobody calls any more, which have broken, and which are being kept pre-computed at a cost for no one. It changes nothing itself; what you get is a ranked list and an order to work through it.
building-a-dashboard
Puts together a PostHog dashboard on the topic you name, reusing charts your team already has, adding only what's missing, and laying the page out so the main numbers stand out.
checking-member-access
Answers who can see or change what in a PostHog project, and why — reading the permission settings the way PostHog actually enforces them.
choosing-trend-or-slope-view
Decides whether a 'how did X change' question needs a full trend line or a start-versus-end slope view, then builds the same underlying query and renders whichever chart actually answers it.
consuming-endpoints-from-client-code
A PostHog endpoint is one of your saved queries, published at a web address. This is how your own app or server calls it: the address, the key it has to send, what goes in the request, and what the errors mean.
copying-endpoints-across-projects
Copies one of your PostHog endpoints — a saved query your own apps call to fetch numbers — into another project, such as from staging to production, or next to the original under a new name.
creating-an-endpoint
Publishing one of your saved queries as something other programs can call over the web — and getting its name, its inputs and its caching right on the first go, because callers break when you change those later.
creating-box-plot-insights
Draws a box plot in PostHog — a chart showing how a number is spread out, from lowest through typical to highest, rather than just its average.
diagnosing-endpoint-performance
One slow or costly published query, taken apart and handed back with a single recommendation: hold the answer in cache longer, pre-compute it, or rewrite the query underneath.
downloading-batch-export-files
Gets a copy of your PostHog data out as a file you can download — events, people, sessions, or the results of a query you write.
exploring-ai-failures
Most AI mistakes never show up as an error: the answer looks fine and is simply wrong. This reads through real conversations from an AI feature and comes back with a ranked list of the ways it goes wrong, each with example links.
exploring-autocapture-events
PostHog records every click on a site automatically; this digs through those records to see what people are pressing, and pins down one button precisely enough to count it from then on.
exploring-endpoint-execution-logs
Every time one of your saved PostHog queries runs it leaves a single line saying how it went; this pulls those lines up to show why a run failed, came back empty, or took too long.
exploring-live-traffic
What is happening on a website this minute — how many people are on it, what they are looking at, which bots are crawling it — in a view that never reaches back further than the last half hour.
exploring-llm-clusters
PostHog automatically bundles an app's AI requests into groups of similar ones; this reads those groups, so a wall of individual requests becomes a handful of recognisable patterns.
exploring-llm-costs
PostHog records the price of every AI call an app makes; this reads those records to answer what the AI is costing and why.
exploring-llm-evaluations
PostHog can grade an app's AI answers automatically — with a code rule, with another AI acting as judge, or by reading the mood of the user's message — and this works out why the grades come out the way they do.
exploring-llm-traces
Replays one run of an AI agent step by step — what it was asked, which tools it reached for, what came back, and where it went off the rails.
exploring-mcp-intent-clusters
Every time an AI assistant calls one of your tools it says what it was trying to achieve; this gathers those stated goals into a handful of recurring ones and shows which of them the assistant cannot find the right tool for.
exploring-mcp-sessions
Takes one run of an AI assistant against your tools and lays out every call it made, in order, with what it was after and where it hit an error.
exploring-mcp-tool-quality
Ranks the tools on your server by how often they break and how slow they are, keeping the call volume next to the rate so a tool with three calls never tops the list.
exploring-mcp-tool-usage
The front door for someone who wants to look at how their tool server is doing but has not picked a question yet — it lays out the questions worth asking and sends you to whatever answers each one.
filtering-bot-traffic
Sorts a site's traffic into real people, search crawlers, AI bots and scripts, so a chart can either leave the machines out or be about them on purpose.
formatting-insight-axes
A chart's numbers can be labelled as times, money or percentages by PostHog itself; this picks the right one, instead of the usual bodge of dividing the data and gluing a unit on the end.
investigate-metric
A number moved and nobody knows why — this first checks whether the move is even real, then goes looking for what changed around that date, and says how sure it is.
managing-endpoint-versions
Saved queries only move forwards — every edit cuts a new version and nothing can point back at an old one — so this is what rolling back, previewing and retiring a version really amount to.
managing-path-cleaning-rules
When /users/123 and /users/456 are really the same page, a report fills up with thousands of one-visit rows; this writes and tests the rules that fold them back into a single readable line.
querying-posthog-data
Finds the right PostHog table and query pattern for a data question, and checks whether an approved company metric already answers it before you calculate the number yourself.
suggesting-path-cleaning-rules
When a site's page reports splinter into thousands of near-identical addresses, PostHog drafts tidy-up rules once a week from that site's own addresses and holds them for review — nothing changes until a person applies them.
turning-engineering-analytics-into-insights
PostHog's engineering dashboard shows how a team's code changes and automated test runs are going, but its views can't be saved or sent on a schedule; this rebuilds those numbers as saved charts you can put on a dashboard and have delivered.
understanding-billing-usage
Your PostHog bill or usage jumped and you want to know why: this pins down which product, which project and which day drove the change, then hands over to that product's own tools to find the cause.
Reviewing code changes7 skills
review-hog-authoring
PostHog has an AI that reviews a team's proposed code changes before they go in; this is how a team writes its own rules for it — a new thing to look for, a stricter or looser bar for what gets posted, or how it answers review comments.
review-hog-blind-spots-general
The last look in PostHog's automatic code review: once the specialist checks have each had their turn, this hunts for real problems none of them caught — and coming back empty-handed counts as a good result.
review-hog-perspective-contracts-security
One of the specialist passes in PostHog's automatic code review, and the one that asks whether a change is safe — whether it could let an attacker in, leak private data, or break other software that relies on it.
review-hog-perspective-logic-correctness
The pass in PostHog's automatic code review that asks the plainest question of a change — does it actually do what it is meant to do? — hunting for wrong sums, forgotten corner cases and database lookups that fetch the wrong rows.
review-hog-perspective-performance-reliability
Will this hold up once real traffic hits it? That is what this pass of PostHog's automatic code review asks of every change, looking for slow database access, errors that vanish silently, and missing time limits or logging.
review-hog-resolution-criteria
After a review leaves comments on a code change, this is the rulebook PostHog's bot follows when it goes back to settle them: make the small, safe fixes itself, turn down the noise with a reason, and hand anything risky to a person.
review-hog-validation-criteria
The filter between PostHog's AI code reviewer and the person whose change it reviewed: each problem the reviewer thinks it found is checked against the real code, and only those that would genuinely hurt get posted — when in doubt, it stays quiet.
Setting PostHog up17 skills
auditing-warehouse-source-health
Somewhere between an outside system and your project, an import has broken. This checks every one of them in a single pass and ranks what it finds by how much damage it is doing.
auditing-warehouse-view-health
Saved queries that are kept pre-computed can quietly stop running, or go on costing storage and compute while nobody reads them. This finds both across a whole project and says which to look at first.
diagnosing-failed-warehouse-syncs
Before restarting a broken import from scratch — which throws away everything already loaded — this works out what actually failed: the connection itself, one table, or a password that changed on the far side.
diagnosing-sdk-health
Old tracking libraries are a quiet cause of odd behaviour. This lists the ones a project is still running behind on, how much of its traffic each still serves, and what to do about them.
instrument-error-tracking
Wires an app up so that when it crashes for a real user you actually hear about it, with the exact line of code that broke rather than a scrambled one.
instrument-feature-flags
Puts a new feature behind a switch you control from outside the code, so it can go live for five percent of people before it goes live for everyone.
instrument-integration
The first-time setup — it gets PostHog into an app the way that particular framework expects, and ties the events it starts sending back to the person who caused them.
instrument-llm-analytics
Every call an app makes to an AI model gets recorded on the way out — what it cost, how long it took, how many tokens it used — whichever provider or framework the app is built on.
instrument-logs
Sends an app's log lines to PostHog as records with named fields you can search and filter, rather than leaving them as loose text nobody can ask questions of.
instrument-metrics
Adds code to an app that keeps count of the things that matter, such as jobs finished, failures and how long requests take, and sends those numbers to PostHog alongside any counting the app already does.
instrument-product-analytics
Works out which of the things people do in a product are worth recording — signing up, paying, giving up — then writes the code that records them and ties each one to a person.
setting-up-a-custom-rest-source
For an API that PostHog has never heard of: you describe in one file how to log in and which addresses to fetch, and try it against live data before anything is switched on.
setting-up-a-data-warehouse-source
Brings a company's data in from somewhere else — Stripe, Hubspot, a Postgres database, hundreds of others — so it sits next to the product data, and does it without passwords ever going through the chat.
skills-store
A shared shelf inside PostHog where a team keeps its saved instructions, so anyone's assistant can pull up the same one instead of being told the job from scratch.
suggesting-data-imports
PostHog only knows what happens inside your product; money, sales deals and support tickets live in other tools — this decides which of those to connect so both sets of data can be read together.
tuning-incremental-sync-config
Changes how an outside table already connected to PostHog gets copied over — new rows only instead of everything, more often or less often — and re-imports from scratch only when the change makes the old copy wrong.
working-with-skills
How to work on a stored skill without dragging the whole thing back and forth — read only the part you need, change only the line you meant to change, and don't overwrite what someone else just saved.
Task comments and plain English2 skills
working-with-task-comments
Teammates can leave comments on the documents and canvases an AI assistant produces inside a PostHog Desktop task; this lets the assistant read every thread in full and act on that feedback, though it can only read comments, never answer or close them.
writing-simplified-technical-english
A plain-writing rulebook borrowed from aircraft maintenance manuals (short sentences, one meaning per word, active voice), applied to whatever an AI assistant writes for people to act on, so it cannot be misread.
Watchers that run on their own44 skills
authoring-error-tracking-alerts
Sets up an error-tracking alert that notifies Slack, a webhook, or Linear when an issue is first created, reopens, or starts spiking, picking the right trigger for how noisy the project already is.
authoring-log-alerts
Picks which services in a project deserve a log alert, works out a threshold that would have fired 0-3 times over the last week using real traffic, and ships it to Slack, a webhook, or Microsoft Teams.
authoring-scouts
A scout is a standing watch on one PostHog project: it wakes on a schedule, looks for whatever is genuinely worth flagging, and files a report. This is how you write one, or bend a ready-made one to fit your own project.
building-loops
Sets up a Loop in PostHog: a standing instruction that hands a job to an AI agent whenever something happens — on a timetable, when a GitHub issue opens, when someone posts in Slack — and sends the result to Slack or email.
creating-ai-subscription
Ask a question once in ordinary words and say how often you want it answered. From then on it is worked out afresh against your own data each time and arrives written up, by email or in Slack.
creating-online-evaluations
Once you know the ways an app's AI tends to get things wrong, this sets up a standing check for each one, so every new AI answer is marked pass or fail and you can see how often each problem still happens.
creating-replay-vision-scanners
A standing watch over every new recording of someone using your site, flagging, scoring, tagging or summarising what it sees. Before it is switched on, what all that will cost is worked out and checked against what the account has left to spend.
exploring-replay-vision-observations
An AI watcher sits over recordings of real people using your site and writes down what it notices; this reads back what it found and turns the parts worth acting on into a task, an insight, or a correction to the watcher.
exploring-scouts
Scouts are scheduled helpers that wake up on their own, look over a project's data, and file a report only when something is worth your attention — this is how you see what yours have been up to.
feature-usage-feed
Nobody can read thousands of AI conversations by hand, so this sets up a second AI to read them and post a running feed into Slack of what people are really using the feature for.
inbox-exploration
PostHog drops what it thinks is worth your attention — error spikes, odd sessions, things noticed in GitHub or Zendesk — into one inbox; this is how you work through it and close each item out.
managing-reminders
A reminder is a nudge to yourself at a set time, with no condition to evaluate and nobody else notified; this sets them up, hangs them off a dashboard or a chart, and clears out the ones you no longer want.
managing-subscriptions
Sets up a dashboard or a chart to be sent to you on a schedule — by email, Slack or a webhook, with an AI write-up alongside it if you want one — so nobody has to remember to go and look.
scanning-experiments-with-replay-vision
Sets an AI to watch the recorded visits of people in a running A/B test and label what each one ran into, so you can see how the two versions are actually experienced, not only how they score.
signals
The Inbox shows tidy summaries; underneath sit the individual observations PostHog made one at a time, and this is how you reach those raw ones — searching them by meaning rather than by keyword.
signals-scout-ai-observability
A watchdog for a team's AI spending and AI failures: it wakes up on its own, looks for a real change in cost, speed, errors or evaluation scores, and says nothing at all unless it finds one.
signals-scout-anomaly-detection
Keeps its own running list of the dashboards a team actually opens, and judges each chart against its own normal week — so a Monday dip is not news, but a real break gets flagged before anyone notices it.
signals-scout-apm
Three times the errors is only worth waking someone for if it is not also three times the traffic — this watches each service for the failures and slowdowns that are real, and lets the rest go.
signals-scout-conversations
Keeps watch on how a team's customer support inbox is coping — replies missing their promised deadline, customers waiting longer for a first answer, tickets piling up faster than they close — and speaks up only when one of those genuinely gets worse.
signals-scout-csp-violations
Browsers quietly block scripts a site's security rules don't allow; this sifts those blocked-script reports for the ones that matter — a page broken for real people, or a script nobody recognises.
signals-scout-customer-analytics
Answers the question a customer success manager asks before a renewal — which accounts are quietly going cold, and which are heating up — every week, instead of waiting for someone to scroll the list.
signals-scout-data-pipelines
A pipeline carrying data out to somewhere else can break with nothing looking wrong — the product runs, the dashboards stay green — so this checks that the ones switched on are genuinely delivering.
signals-scout-data-warehouse
Data coming in from Stripe, Hubspot or a database can stop arriving while the table it feeds still looks fine, and every missed hour is a hole nobody fills unless somebody notices — this notices.
signals-scout-error-tracking
A thousand errors from one person is a stuck loop; a thousand errors from nine hundred people is an incident — this reads a team's crashes with that difference in mind and speaks up only for the second kind.
signals-scout-experiments
Checks that a running A/B test is still measuring what it claims to measure — an even split, uncontaminated data, a metric that can actually answer the question — and deliberately says nothing about which side is winning.
signals-scout-feature-flags
Watches the gap between what a feature switch says it is doing and what the code is actually asking for — the wiring between the two, not which features ought to be on.
signals-scout-general
The generalist of the fleet — it wanders the whole project rather than one corner of it, and covers whatever no specialist is watching.
signals-scout-health-checks
PostHog runs its own setup checks and can pile up a hundred and eighty complaints; this is the layer that reads them, works out that most share a handful of causes, and hands a person the four things worth doing.
signals-scout-inbox-validation
After a fix ships, did the problem actually stop? This one waits a while, measures the same thing again, and speaks up only when the answer is no.
signals-scout-insight-alerts
The team already decided which numbers are worth an alert; the trouble is that alerts go off and nobody sees them, so once a day this picks out the firings that most likely got missed.
signals-scout-logs
Reads through an app's log lines and holds them against the same week before, so a real shift shows up as a shift rather than disappearing into the usual noise.
signals-scout-mcp-tool-calls
When AI assistants use the tools on a team's tool server, some tools keep failing, confuse the assistant into retrying, or run slow; this finds those on a schedule and files one report per owning team, each tool with a suggested fix.
signals-scout-observability-gaps
Every other watcher here reports problems; this one reports what is missing — the things a product does constantly that nobody has put a chart or an alert on yet.
signals-scout-pr-follow-up
Comes back a day or a week after a code change ships and checks what its author rarely gets round to: did the fix actually stop the problem, did the promised improvement show up, and did it quietly break something else.
signals-scout-product-analytics
Funnels and retention charts slide slowly and nobody opens them every week; this watches them for a genuine drop in the rate, as opposed to simply fewer people turning up at the top.
signals-scout-replay-vision
An AI that reviews session recordings judges one session at a time, so nothing ever adds them up; this does the adding up, and checks that the reviewer has not quietly stopped reviewing.
signals-scout-revenue-analytics
The revenue figures in PostHog are only as good as the Stripe sync and the purchase events feeding them; this catches those going wrong before anyone in finance quotes a number that is out of date.
signals-scout-session-replay
Session recording makes two promises — that it is recording at all, and that the recordings show where people struggle — and this catches either one quietly failing, before a day of lost recordings is gone for good.
signals-scout-skills-store
Checks the skills a team keeps in its shared PostHog store for mistakes that break them — dead links, leaked keys, a description too vague for an assistant to find — and files a ready-to-paste fix for each broken one.
signals-scout-surveys
Nobody reads every answer a survey collects. This keeps watch over them and speaks up when a rating starts sliding or the same complaint shows up again and again.
signals-scout-tasks
When a team hands work to AI agents through PostHog's task list, this keeps an eye on whether that work actually gets done — and tells a real fault hitting everyone apart from one stuck job being retried over and over.
signals-scout-web-analytics
Watches where your website's visitors come from and where they land, and tells you when one part of that stops behaving — an ad channel drying up, a page that suddenly turns people away.
signals-scout-web-vitals
Google grades every web page on how fast it loads, how quickly it reacts to a click, and whether things jump around while it loads; this finds the pages that score badly, whether they just got worse or have always been slow, and names the likely cause and the fix.
working-with-scouts
The day-to-day guide to managing PostHog's scouts, the automated watchers that file reports on a project: how to hand them a job, act on what they report, and steer them until what they flag matches what your team cares about.
Working out what broke16 skills
diagnosing-ci-and-merge-bottlenecks
Shipping feels slower than it used to and nobody can say where the days go. This measures a repository's pull requests from opened to merged and names the step that is actually costing the time.
diagnosing-missing-recordings
Why is there no recording of this visit? The tracking code leaves a trail of clues on every event it sends, and this reads them to say which link in the chain dropped it.
diagnosing-stacktrace-symbolication
An error report that should point at a line of your own code points at scrambled characters instead. This checks the four places that translation can break: how the app was built, what that produced, what reached PostHog, and what the error itself carried.
exploring-apm-traces
When one request passes through many different services on its way, this follows the whole journey and points at the step that was slow or the one that broke.
finding-replay-for-issue
Picks the single most useful session recording linked to an error tracking issue, out of what can be hundreds, instead of leaving someone to guess.
finding-sessions-to-watch
Turns a vague wish to watch some session recordings into a short, filtered shortlist worth actually watching, instead of an unsorted dump of everything.
grouping-noisy-errors
One bug can show up as fifty separate entries in the error list when its message carries a random ID or a changing file path; this folds them back into one and sets a rule so new copies land there too.
investigating-ci-failures
When an automatic test run fails, this says whose fault it is: the developer's own change, something already broken on the main branch, or a test that fails at random. If it was the main branch, it names the change, its author, and whether a fix has landed.
investigating-error-issue
Takes one error an app is throwing and works out the whole story behind it: who it hits, when it started, what sets it off, and what to do about it.
investigating-logs
Answers 'did my change break anything?' or 'why are errors up?' from an app's logs, by boiling millions of lines down to at most 200 recurring message patterns and comparing them with an earlier, healthy stretch of time.
investigating-metric-anomalies
A server number is behaving badly — lag climbing, errors spiking — and this works out exactly when and where it started, then reads the logs from that precise moment until something explains it.
investigating-replay
Someone hands you a recording of one visit, and this pulls together the whole picture around it — who the person was, what they clicked, what broke, and whether it is a bug you already know about.
resolving-ingestion-warnings
When events go missing or counts come in lower than they should, PostHog has usually left a note about what it rejected on the way in; this reads those notes, worst first, and traces each one back to a fix in the code that sends the data.
suppressing-noisy-errors
Some errors are never yours to fix — a browser extension misbehaving, a bot hammering your site — and they drown out the ones that matter. This sets up a tight rule that throws those away before they are ever recorded.
triaging-error-issues
Most apps are throwing hundreds of errors at any moment and almost none of them matter; this picks out the handful that are new, spreading, or hitting a lot of people, and says what to do about each one.
triaging-visual-review-runs
Before a code change can be merged, pictures of the screens are compared with the saved ones and anything that looks different holds it up. This tells you whether the difference is a real design change or just noise, and lets you sign it off.
No skills in this package match the current search or filters.
PLUGINS1 item
PLUGIN
posthog
Access PostHog analytics, feature flags, experiments, error tracking, and insights directly from your AI coding tool. Optionally capture Claude Code sessions to PostHog LLM Analytics.
AGENT PERSONALITIES1 item
AGENT PERSONALITY
error-analyzer
Hand it a batch of errors instead of one. It pulls the recent errors, opens each of them, puts the ones with a shared cause together, counts the people each one reaches, and comes back with an order to fix them in. It also says whether a recent release or a flag being switched lines up with when they started.
MCP SERVERS1 item
MCP SERVER
posthog http
Integrates with PostHog for feature flag management and error tracking.
INSTALL
Install
SINGLE SKILL
Install a skill by name
Run this outside your AI tool, using Node.js 22.20.0 or newer. Skills CLI 1.7.2 skips skill selection; prompts cancel installation without an interactive terminal. If choosing Project when asked about installation scope, open your project's folder before running this.
Install checklist
- Check selected tools if a picker appears; Claude Code may be unchecked under
Additional agents. ↑/↓ moves, Space toggles selections, Enter confirms. - Without a tool picker, check
Installing to:for your intended tool. Stop if it names a different tool. - If asked, choose
Symlink (Recommended)for shared files orCopy to all agentsfor separate copies; review the summary before confirming installation. Install the find-skills skill?defaults toYes, adding another skill for all projects. ChooseNoif you don't want that extra installation.
Find the skill name in the Skills tab. Open that skill's panel before copying a command: some skills need files or other skills from this package, and the panel shows the install route to use.
npx skills add posthog/ai-plugin --skill <YOUR_SKILL_NAME> --full-depthClaude Code
Add PostHog's marketplace, then install the plugin
claude plugin marketplace add PostHog/ai-pluginclaude plugin install posthog@posthogRun both lines in a terminal. PostHog offers this as the alternative to the one-line claude plugin install posthog: it adds PostHog's own marketplace from this repository, then installs the same posthog plugin from it. Afterwards, start claude, run /mcp, choose plugin:posthog:posthog and log in to PostHog in your browser.
Codex
Add PostHog's marketplace, then open Codex
codex plugin marketplace add PostHog/ai-plugincodexRun both lines in a terminal: the first adds PostHog's marketplace, the second starts Codex. Inside Codex, type /plugins, select PostHog and install it.
Gemini CLI
gemini extensions install https://github.com/PostHog/ai-pluginRun it in a terminal, not inside a Gemini CLI session. It installs the repository as a Gemini CLI extension, which connects Gemini CLI to PostHog's MCP server. Restart Gemini CLI if it is already open.