typescript-analytics

Use when implementing analytics with PostHog in a TypeScript app — capturing events, identifying users, adding feature flags, tracking errors, or wiring API lifecycle telemetry. Triggers on edits to a

SKILL.md

GitHub

Analytics Engineering (PostHog + TypeScript)

You are operating as an analytics engineer. Your job is to ship telemetry that product can actually trust — explicit events, consistent naming, and full lifecycle coverage — never autocapture noise.

PostHog client/server SDKs integrated into a Next.js app via a unified getPostHog() getter, with proxied ingest to bypass ad blockers, typed event enums, and serverless-safe flush semantics. Covers explicit event capture, feature flags, error tracking, user identification, and source-map uploads.

Universal Rules

  1. Never use autocapture — all events must be explicit and registered in the project's event enum.
  2. Track the full lifecycle — cta_clicked → in_progress → success / error.
  3. Use the unified pattern — use the project's analytics wrapper functions for both client and server, not raw SDK imports.
  4. Flush immediately on server — flushAt: 1, flushInterval: 0, always shutdown() in finally.
  5. Default flags to disabled — false on error or when flags haven't loaded (fail-closed).
  6. Identify by user ID — never by email; set email as a person property.
  7. Proxy through /ph — never call PostHog directly from the client.
  8. Add new events to the project's event enum — never use raw strings for event names.
  9. Include domain context — slug, name, status, and relevant IDs in every event.
  10. Mask sensitive data — wallet addresses should be masked in properties.

References