posthogsolid

# PostHog (connected) This connection is `${id}`: `$POSTHOG_HOST`, `$POSTHOG_PROJECT_ID` and `$POSTHOG_API_KEY`. Everything goes through **`posthog-cli api`**, PostHog's own agent-first surface (the same tool catalogue as their MCP server, bundled inside the binary). It reads those three names unsuffixed, so hand them over per command — define this once per shell: ```sh ph() { POSTHOG_HOST=$POSTHOG_HOST POSTHOG_PROJECT_ID=$POSTHOG_PROJECT_ID POSTHOG_API_KEY=$POSTHOG_API_KEY posthog-cli api "$@"; } ``` `posthog-cli` reaches PATH when the sandbox is next rebuilt after this card was added. Until then put `npx -y @posthog/cli@latest` in place of `posthog-cli` in that line: same tool, slower first call. ## The loop `ph --agent-help` is the canonical instruction sheet, generated from the same binary as the tools, so it cannot be stale. Read it once per session before anything you have not done here before. Then four commands: - `ph search '<regex>'` — find the tool. There are hundreds and their names track the API, so search, never guess. - `ph info <tool>` — its schema and its own rules. Run it once and reuse; when a field comes back with a `hint` instead of a shape, drill in with `ph schema <tool> <field>`. - `ph call <tool> '<json>'` — run it. `--dry-run` checks the JSON against the schema without executing. - `ph skill list` · `ph skill install <id>` — PostHog's own task skills (`investigating-replay`, `audit-session-replay`, error tracking per framework). They instal