The PostHog plugin for Claude Code: what it connects, and what it does not

The problem this solves

Your product analytics live in one tool and your agent lives in another. So you describe the metric you are looking at, paste a screenshot, explain the schema, and hope the answer accounts for the thing you forgot to mention.

The gap is not knowledge. It is access. An agent that cannot query your actual events is guessing about your actual product.

This plugin closes that gap for PostHog, and it does something most analytics integrations do not: it also teaches the agent how PostHog itself is built.

Two jobs in one plugin, and you probably want one of them

This is the thing to understand before installing, because the component list reads as two different products stapled together.

Job one: use PostHog from your agent. Two MCP servers, posthog-local and phrocs, connect the agent to analytics, session replay, feature flags, error tracking, the data warehouse, and LLM observability.

Job two: contribute to PostHog. Most of the agents are conventions enforcement for the PostHog codebase, not for yours.

Four of them are ingestion pipeline specialists, and the split between them is unusually precise:

Agent	What it checks
pipeline-step-doctor	conventions inside an individual step
pipeline-composition-doctor	how steps are assembled and concurrency chosen
pipeline-result-doctor	result constructors and error handling
pipeline-testing-doctor	how pipeline tests are written and debugged

If you do not work on PostHog's ingestion pipeline, those four will never fire for you, and that is fine. It does mean the raw component count overstates what most installers will actually use.

What fires for everyone

Several components are general purpose and do not assume you are a PostHog contributor:

• systematic-debugger diagnoses bugs and unexpected behaviour rather than guessing at fixes
• code-reviewer reviews recently written or modified code
• test-writer writes test suites for existing code
• prompt-engineer creates and refines prompts for LLMs
• conventions carries PostHog's frontend and backend coding conventions

access-control and activity-log-expert sit in between. They are specific to PostHog's permissions and audit logging systems, which matters if you are extending a self-hosted instance.

How it compares

Both are large, high signal data plugins on Flowy with very different centres of gravity.

	posthog/posthog	k-dense-ai/scientific-agent-skills
Components indexed	170	163
Shape	skills, agents, commands, and 2 MCP servers	skills only
Connects to a live service	yes, via MCP	no
Best when	you want the agent reading your real product data	you want analysis technique, not a data connection

The MCP servers are the deciding factor. If you want your agent to answer questions about what your users actually did, you need a live connection, and this plugin has one. If you want reasoning technique applied to data you already have in hand, you do not.

The honest caveat

The component list is dominated by contributor tooling. That is not a criticism, it is what happens when a company open sources the plugin it uses internally, and it is more useful than a marketing integration would be. But go in knowing that a large fraction of what you install exists to help people work on PostHog, not to help PostHog work for you.

Getting it

Install from the listing page linked at the top of this guide. Flowy indexes the full component set so you can see that split before installing rather than after.