# PostHog for Claude Code: what it does and how to install it

> posthog/posthog is a Claude Code plugin with 170 indexed components and two MCP servers that connect an agent to analytics, session replay, feature flags, error tracking and LLM observability. Most of its agents, however, enforce conventions for contributing to PostHog rather than for using it.

Canonical: https://www.flowy.sh/plugins/posthog-posthog/guide
Published: 2026-08-22
Updated: 2026-10-29
Author: Maximo Correa

## What problem does PostHog solve?

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.

## Which of the two jobs in PostHog's plugin do you want?

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 who installs PostHog's plugin?

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 does PostHog compare?

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.

## What is the catch with the PostHog plugin?

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.

## How do I install PostHog in Claude Code?

Install from [the install card on the listing page](https://www.flowy.sh/listings/posthog-posthog#install). Flowy indexes the
full component set so you can see that split before installing rather than after.

Sources: [posthog/posthog on GitHub](https://github.com/posthog/posthog), [posthog/posthog README](https://github.com/posthog/posthog#readme)

## Common questions

### Do I need to be a PostHog customer for this to be useful?

For the MCP servers, yes. posthog-local and phrocs connect to your analytics, so they need an instance to talk to. Several components are general purpose and do not, including systematic-debugger, code-reviewer, test-writer and prompt-engineer.

### Why are four agents all about the ingestion pipeline?

They check different layers of the same system: pipeline-step-doctor covers an individual step, pipeline-composition-doctor covers how steps are assembled, pipeline-result-doctor covers result handling, and pipeline-testing-doctor covers the tests. They fire for people working on PostHog, not on your codebase.

### Does the component count overstate what I get?

For most installers, yes, and that is worth knowing before rather than after. A large fraction of the set is contributor tooling for PostHog itself. That is what happens when a company open sources the plugin it uses internally, and it is more honest than a marketing integration.

## Related

- [The listing page](https://www.flowy.sh/listings/posthog-posthog): Install command, components and repository
- [Alternatives to this plugin](https://www.flowy.sh/alternatives/posthog-posthog): Peers in its category, ranked by stars
- [The Claude Code plugin marketplace](https://www.flowy.sh/marketplace/plugins): How plugins install, and every plugin in the index
- [Mem0 for Claude Code: what it does and how to install it](https://www.flowy.sh/plugins/mem0ai-mem0/guide): another plugin guide
- [superpowers for Claude Code: what it does and how to install it](https://www.flowy.sh/plugins/superpowers-flow/guide): another plugin guide