Instrument Integration

PostHogOfficialCreated by PostHog

Skill
Tool integration
Data and AI
MIT
Low risk

From the author

Add PostHog SDK integration to your application. Use when setting up PostHog for the first time or reviewing PRs that need PostHog initialization. Covers SDK installation, provider setup, and basic configuration for any framework.

— the description by PostHog

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured, multi-step procedure for integrating the PostHog SDK into a wide range of web, mobile, and backend frameworks. It handles the detection of the project environment, installation of the appropriate SDK, initialization, user identification, and secure configuration of environment variables. The skill emphasizes following framework-specific patterns and maintaining an analytics contract, ensuring that PostHog is implemented consistently without disrupting existing application logic.

What it does

Detects the project's framework, language, and package manager.
Installs the correct PostHog SDK for the identified platform.
Configures PostHog initialization and provider setup based on framework-specific references.
Implements user identification logic for login and signup events.
Manages environment variables for project tokens and host URLs securely.
Verifies the integration and performs minimal cleanup.

When to use it

When setting up PostHog in a project for the first time.
When reviewing pull requests that require PostHog initialization.
When adding analytics to a new application across supported frameworks.
When migrating or updating PostHog configurations in an existing codebase.

Advantages

Ensures consistent implementation across diverse technology stacks.
Prevents hardcoding of sensitive project tokens and host URLs.
Follows established framework-specific best practices and patterns.
Minimizes the risk of breaking application boot or build processes.
Automates the repetitive aspects of SDK setup and environment configuration.

Usage examples

“Set up PostHog in my Next.js project.”: The agent will detect the Next.js environment, install the PostHog SDK, configure the necessary provider, and set up environment variables in .env.local.
“Integrate PostHog into this Android app.”: The agent will identify the Android/Kotlin structure, initialize PostHog in the Application class, and guide the setup of local.properties for configuration.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/posthog/instrument-integration/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip instrument-integration.zip -d .agents/skills

Documentation by PostHog

Add PostHog SDK integration

Use this skill to add the PostHog SDK to an application. Use it when setting up PostHog for the first time, or reviewing PRs that need PostHog initialization. Covers SDK installation, provider setup, and basic configuration. Supports any framework or language.

Supported frameworks and languages: Next.js, React, React Router, Vue, Nuxt, TanStack Start, SvelteKit, Astro, Angular, Django, Flask, FastAPI, Laravel, PHP, Ruby on Rails, Go, Elixir, Android, iOS, Swift, Flutter, React Native, Expo, Node.js, and vanilla JavaScript.

Instructions

Follow these steps IN ORDER:

STEP 1: Analyze the codebase and detect the platform.

Look for dependency files (package.json, pubspec.yaml, Podfile, Package.swift, requirements.txt, Gemfile, composer.json, go.mod, mix.exs, etc.) to determine the framework and language.

Look for lockfiles (pnpm-lock.yaml, package-lock.json, yarn.lock, bun.lockb, go.sum, pubspec.lock, Podfile.lock, Package.resolved, mix.lock) to determine the package manager.

Check for existing PostHog setup. If PostHog is already installed and initialized, do not modify its code. Inform the user and skip to verification.

STEP 2: Research integration. 2.1. Find the reference file below that matches the detected framework — it is the source of truth for SDK initialization, provider setup, and configuration patterns. Read it now. 2.2. If no reference matches, fall back to your general knowledge and web search. Use posthog.com/docs as the primary search source.

STEP 3: Install the PostHog SDK.

Add the PostHog SDK package for the detected platform. Do not manually edit package.json — use the package manager's install command.

STEP 4: Initialize PostHog.

Follow the framework reference for where and how to initialize. This varies significantly by framework (e.g., instrumentation-client.ts for Next.js 15.3+, AppConfig.ready() for Django, create_app() for Flask).
Set up the PostHog provider/wrapper component if the framework requires one.

STEP 5: Identify users.

Add PostHog identify() calls on the client side during login and signup events.
If both frontend and backend exist, pass the client-side session and distinct ID using X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID headers to the server-side code.

STEP 6: Set up environment variables.

Check if the project already has PostHog environment variables configured (e.g. in .env, .env.local, or framework-specific env files). If valid values already exist, skip this step.
If the PostHog project token is missing, use the PostHog MCP server's projects-get tool to retrieve the project's api_token. If multiple projects are returned, ask the user which project to use. If the MCP server is not connected or not authenticated, ask the user for their PostHog project token instead.
For the PostHog host URL: check the projects-get MCP response for a region field — US maps to https://us.i.posthog.com, EU maps to https://eu.i.posthog.com. If the region is not available from the MCP response or from existing project configuration, ask the user: "Are you on PostHog US Cloud or EU Cloud?" Do not assume US Cloud.
Write these values to the appropriate env file (e.g. .env.local for Next.js, .env for others) using the framework's naming convention.
Reference these environment variables in code instead of hardcoding them.

STEP 7: Verify and clean up.

Check the project for errors. Look for type checking or build scripts in package.json.
Ensure any components created were actually used.
Run any linter or prettier-like scripts found in the package.json, but ONLY on the files you have edited or created during this session. Never run formatting or linting across the entire project's codebase.

Reference files

references/EXAMPLE-next-app-router.md - next-app-router example project code
references/EXAMPLE-next-pages-router.md - next-pages-router example project code
references/EXAMPLE-react-react-router-6.md - react-react-router-6 example project code
references/EXAMPLE-react-react-router-7-framework.md - react-react-router-7-framework example project code
references/EXAMPLE-react-react-router-7-data.md - react-react-router-7-data example project code
references/EXAMPLE-react-react-router-7-declarative.md - react-react-router-7-declarative example project code
references/EXAMPLE-react-vite.md - react-vite example project code
references/EXAMPLE-nuxt-3-6.md - nuxt-3-6 example project code
references/EXAMPLE-nuxt-4.md - nuxt-4 example project code
references/EXAMPLE-vue-3.md - vue-3 example project code
references/EXAMPLE-react-tanstack-router-file-based.md - react-tanstack-router-file-based example project code
references/EXAMPLE-react-tanstack-router-code-based.md - react-tanstack-router-code-based example project code
references/EXAMPLE-tanstack-start.md - tanstack-start example project code
references/EXAMPLE-sveltekit.md - sveltekit example project code
references/EXAMPLE-astro-static.md - astro-static example project code
references/EXAMPLE-astro-view-transitions.md - astro-view-transitions example project code
references/EXAMPLE-astro-ssr.md - astro-ssr example project code
references/EXAMPLE-astro-hybrid.md - astro-hybrid example project code
references/EXAMPLE-angular.md - angular example project code
references/EXAMPLE-javascript-node.md - javascript-node example project code
references/EXAMPLE-javascript-web.md - javascript-web example project code
references/EXAMPLE-django.md - django example project code
references/EXAMPLE-flask.md - flask example project code
references/EXAMPLE-fastapi.md - fastapi example project code
references/EXAMPLE-python.md - python example project code
references/EXAMPLE-laravel.md - laravel example project code
references/EXAMPLE-php.md - php example project code
references/EXAMPLE-ruby-on-rails.md - ruby-on-rails example project code
references/EXAMPLE-ruby.md - ruby example project code
references/EXAMPLE-android.md - android example project code
references/EXAMPLE-swift.md - swift example project code
references/EXAMPLE-react-native.md - react-native example project code
references/EXAMPLE-expo.md - expo example project code
references/next-js.md - Next.js
references/react.md - React
references/react-router-v6.md - React router v6
references/react-router-v7-framework-mode.md - React router v7 framework mode (remix v3)
references/react-router-v7-data-mode.md - React router v7 data mode
references/react-router-v7-declarative-mode.md - React router v7 declarative mode
references/nuxt-js-3-6.md - Nuxt.js (v3.0 to v3.6)
references/nuxt-js.md - Nuxt.js
references/vue-js.md - Vue.js
references/tanstack-start.md - Tanstack start
references/svelte.md - Svelte
references/astro.md - Astro
references/angular.md - Angular
references/js.md - JavaScript web
references/posthog-js.md - PostHog JavaScript web SDK
references/node.md - Node.js
references/posthog-node.md - PostHog Node.js SDK
references/django.md - Django
references/flask.md - Flask
references/python.md - Python
references/posthog-python.md - PostHog python SDK
references/dotnet.md - .net
references/elixir.md - Elixir
references/go.md - Go
references/laravel.md - Laravel
references/php.md - Php
references/ruby-on-rails.md - Ruby on rails
references/ruby.md - Ruby
references/android.md - Android
references/ios.md - Ios
references/usage.md - Ios SDK usage
references/configuration.md - Ios SDK configuration
references/flutter.md - Flutter
references/react-native.md - React native
references/identify-users.md - Identify users
references/COMMANDMENTS.md - Framework-specific rules the integration must follow

Each framework reference contains SDK-specific installation, initialization, and usage patterns. Find the one matching the user's stack.

Key principles

Environment variables: Always use environment variables for PostHog keys. Never hardcode them.
Minimal changes: Add PostHog code alongside existing integrations. Don't replace or restructure existing code.
Match the example: Your implementation should follow the example project's patterns as closely as possible.
Analytics contract: Treat event names, property names, and feature flag keys as part of an analytics contract. Reuse existing names and patterns found in the project. When introducing new ones, make them clear, descriptive, and consistent with existing conventions.

Files

ATTRIBUTION.mdAdded by AutoGineer952 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md8.8 KiB
references/COMMANDMENTS.md1.5 KiB
references/EXAMPLE-android.md49.8 KiB
references/EXAMPLE-angular.md23.1 KiB
references/EXAMPLE-astro-hybrid.md27.5 KiB
references/EXAMPLE-astro-ssr.md27.6 KiB
references/EXAMPLE-astro-static.md19.6 KiB
references/EXAMPLE-astro-view-transitions.md23.3 KiB
references/EXAMPLE-django.md30.7 KiB
references/EXAMPLE-expo.md35.1 KiB
references/EXAMPLE-fastapi.md40.9 KiB
references/EXAMPLE-flask.md32.4 KiB
references/EXAMPLE-javascript-node.md9.0 KiB
references/EXAMPLE-javascript-web.md11.8 KiB
references/EXAMPLE-laravel.md59.3 KiB
references/EXAMPLE-next-app-router.md17.6 KiB
references/EXAMPLE-next-pages-router.md19.1 KiB
references/EXAMPLE-nuxt-3-6.md22.3 KiB
references/EXAMPLE-nuxt-4.md28.9 KiB
references/EXAMPLE-php.md13.0 KiB
references/EXAMPLE-python.md11.6 KiB
references/EXAMPLE-react-native.md46.0 KiB
references/EXAMPLE-react-react-router-6.md13.5 KiB
references/EXAMPLE-react-react-router-7-data.md20.1 KiB
references/EXAMPLE-react-react-router-7-declarative.md15.0 KiB
references/EXAMPLE-react-react-router-7-framework.md32.5 KiB
references/EXAMPLE-react-tanstack-router-code-based.md19.6 KiB
references/EXAMPLE-react-tanstack-router-file-based.md18.3 KiB
references/EXAMPLE-react-vite.md12.4 KiB
references/EXAMPLE-ruby-on-rails.md38.0 KiB
references/EXAMPLE-ruby.md10.0 KiB
references/EXAMPLE-sveltekit.md18.6 KiB
references/EXAMPLE-swift.md18.8 KiB
references/EXAMPLE-tanstack-start.md29.9 KiB
references/EXAMPLE-vue-3.md17.9 KiB
references/android.md33.3 KiB
references/angular.md16.5 KiB
references/astro.md15.8 KiB
references/configuration.md17.2 KiB
references/django.md14.9 KiB
references/dotnet.md25.8 KiB
references/elixir.md17.6 KiB
references/flask.md8.1 KiB
references/flutter.md42.8 KiB
references/go.md20.1 KiB
references/identify-users.md12.2 KiB
references/ios.md8.0 KiB
references/js.md16.1 KiB
references/laravel.md13.1 KiB
references/next-js.md18.3 KiB
references/node.md45.6 KiB
references/nuxt-js-3-6.md11.4 KiB
references/nuxt-js.md15.1 KiB
references/php.md23.7 KiB
references/posthog-js.md51.6 KiB
references/posthog-node.md33.9 KiB
references/posthog-python.md69.3 KiB
references/python.md52.2 KiB
references/react-native.md59.9 KiB
references/react-router-v6.md13.6 KiB
references/react-router-v7-data-mode.md13.5 KiB
references/react-router-v7-declarative-mode.md13.7 KiB
references/react-router-v7-framework-mode.md20.2 KiB
references/react.md21.9 KiB
references/ruby-on-rails.md19.7 KiB
references/ruby.md25.5 KiB
references/svelte.md14.6 KiB
references/tanstack-start.md12.8 KiB
references/usage.md29.2 KiB
references/vue-js.md13.4 KiB

references/configuration.md

AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

iOS SDK configuration

Canonical URL: https://posthog.com/docs/libraries/ios/configuration

Cloud region: This page uses US Cloud hosts. For an EU Cloud project, use https://eu.i.posthog.com instead of https://us.i.posthog.com (ingestion host).

Autocapture configuration

You can enable or disable autocapture through the PostHogConfig object.

Tracing headers

Use tracingHeaders to connect iOS network requests to backend events, errors, and LLM traces captured by a server-side PostHog SDK:

let configuration = PostHogConfig(projectToken: "<ph_project_token>", host: "https://us.i.posthog.com")
configuration.tracingHeaders = ["api.example.com"]
PostHogSDK.shared.setup(configuration)

Hostnames are matched exactly and should not include protocols, paths, ports, or wildcard subdomains. Matching URLSession requests include X-POSTHOG-DISTINCT-ID and X-POSTHOG-SESSION-ID when those values are available.

Tracing headers require method swizzling, so configuration.enableSwizzling must remain true.

Flush configuration

The iOS SDK uses an internal queue to make calls fast and non-blocking. It also batches requests and flushes asynchronously, making it perfect to use in any part of your mobile app.

You can configure how many events queue before flushing with flushAt. Setting this to 1 will send events immediately and will use more battery. The default is 20.

You can also configure the flush interval with flushIntervalSeconds (default 30), after which queued events are sent regardless of how many have been gathered:

configuration.flushAt = 1
configuration.flushIntervalSeconds = 30

You can also manually flush the queue to start sending events immediately instead of waiting for the next batch:

PostHogSDK.shared.capture("logged_out")
PostHogSDK.shared.flush()

Flushing is best-effort and asynchronous – it starts sending queued events in the background but doesn't wait for the request to finish, so it isn't a delivery guarantee.

Amending, dropping or sampling events

Since version 3.28.0, you can provide a BeforeSendBlock function when initializing the SDK to amend, drop or sample events before they are sent to PostHog.

⚠️ Note: This replaces the deprecated propertiesSanitizer option and provides more flexibility in modifying events. You can achieve the same functionality as propertiesSanitizer by using a BeforeSendBlock that mutates the event's properties in place.

🚨 Warning: Amending and sampling events is advanced functionality that requires careful implementation. Core PostHog features may require 100% of unmodified events to function properly. We recommend only modifying or sampling your own custom events if possible, and preserving all PostHog internal events in their original form.

Redacting information in events

BeforeSendBlock gives you one place to edit or redact information before it is sent to PostHog. For example:

Redact URLs in event properties

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Redact URLs
    if let url = event.properties["url"] as? String {
        event.properties["url"] = url.map { _ in "*" }.joined()
    }
    return event
}

Redact sensitive information from event properties

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Redact sensitive information
    if let email = event.properties["email"] as? String {
        event.properties["email"] = email.map { _ in "*" }.joined()
    }

    return event
}

Drop events by event name

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Drop all events named "Stale Event"
    if event.event == "Stale Event" {
        return nil
    }
    return event
}

Filter autocaptured screen views

You can stop specific screens from being autocaptured by filtering them in your before-send hook. Return null for any $screen event whose $screen_name matches a screen you don't want to track, and it's dropped before being sent – keeping unwanted screen views out of your event log.

Because it's just a function, you can filter however you like – an ignorelist (drop the screens you name), an allowlist (invert the check to capture only the screens you name), or any custom rule such as a name prefix, a regex, or a check against the event's properties.

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

let ignoredScreens: Set<String> = ["Splash", "Debug"]

config.setBeforeSend { event in
    if event.event == "$screen",
       let screenName = event.properties["$screen_name"] as? String,
       ignoredScreens.contains(screenName) {
        return nil
    }
    return event
}

Sampling events

Sampling lets you choose to send only a percentage of events to PostHog. It is a good way to control your costs without having to completely turn off features of the SDK.

Sample events by event name

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend { event in
    // Sample 10% of Sampled Event events
    if event.event == "Sampled Event" {
        if Double.random(in: 0...1) < 0.1 {
            event.properties["$sample_type"] = ["sampleByEvent"]
            event.properties["$sample_threshold"] = 0.1
            event.properties["$sampled_events"] = ["Sampled Event"]
            return event
        }
        return nil
    }
    return event
}

Chaining multiple BeforeSendBlocks

You can provide an array of BeforeSendBlock functions to be called one after the other:

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")

config.setBeforeSend(
    // First block: Drop all events named "Stale Event"
    { event in
        if event.event == "Stale Event" {
            return nil
        }
        return event
    },
    // Second block: Redact sensitive information
    { event in
        if let email = event.properties["email"] as? String {
            event.properties["email"] = email.map { _ in "*" }.joined()
        }
        return event
    }
)

Note: When chaining beforeSend blocks, order is important. The first block is executed first and the mutated event is passed along to the second block, and so on. If at any point in the chain the event is dropped, any subsequent blocks will not be executed.

Setting up app groups

Configure App Groups: Set up an App Group in Xcode for your main app and extension targets
Configure PostHog: Use the same App Group identifier in all targets:

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")
config.appGroupIdentifier = "group.com.yourcompany.yourapp"
PostHogSDK.shared.setup(config)

Method swizzling

Method swizzling is a technique that enables the SDK to intercept and modify method calls at runtime to provide advanced features like screen view tracking, element interactions, session replay, surveys, and more.

Method swizzling is enabled by default, but can be disabled by setting the relevant config option to false in the PostHogConfig object:

Feature	Description	Config option
Screen view tracking	Automatically captures when view controllers are presented	`config.captureScreenViews`
Element interactions	Automatically tracks user interactions with UI elements	`config.captureElementInteractions`
Rage clicks	Automatically captures `$rageclick` events for rapid repeated taps in the same area (iOS/macCatalyst, UIKit)	`config.rageClickConfig.enabled`
Session replay	Records user sessions	`config.sessionReplay`
Surveys	Displays surveys at appropriate times	`config.surveys`
Advanced metrics tracking	Provides more precise session ID calculation and rotation by detecting user activity and idleness	N/A

Disabling all method swizzling

Since version 3.34.0, you can opt out of all swizzling using the enableSwizzling configuration option. When you disable swizzling, the SDK disables the features listed above.

let config = PostHogConfig(projectToken: "<ph_project_token>", host: "<ph_api_client_host>")
config.enableSwizzling = false
PostHogSDK.shared.setup(config)

Note: When method swizzling is disabled, features that depend on it will not work even if they are individually enabled in the config. For example, if you set config.sessionReplay = true and config.enableSwizzling = false, session replay will not be enabled.

Session metrics management

Method swizzling is particularly important for accurate session metrics tracking. With swizzling enabled, the SDK can better detect user activity and idle times to provide a better session rotation.

With swizzling disabled, the SDK only uses application open/backgrounded events to detect user activity, which can lead to a sub-optimal session calculation.

Custom keyboard extensions

Custom keyboard extensions have stricter security rules than other extension types. To use PostHog in a custom keyboard, the keyboard must have Open Access permission enabled. This permission is required for network requests and write access to shared containers.

Users must explicitly grant Open Access in Settings > General > Keyboard > Keyboards > [Your Keyboard] > Allow Full Access.

All configuration options

The PostHogConfig object contains several other settings you can toggle:

Attribute	Description
`flushAt` Type: Integer Default: `20` (`5` on tvOS)	The number of queued events that the posthog client should flush at. Setting this to `1` will not queue any events and will use more battery.
`flushIntervalSeconds` Type: TimeInterval Default: `30`	The amount of time to wait before each tick of the flush timer, in seconds. Smaller values will make events delivered in a more real-time manner and also use more battery. A value smaller than 10 seconds will seriously degrade overall performance.
`maxQueueSize` Type: Integer Default: `1000` (`100` on tvOS)	The maximum number of items to queue before starting to drop old ones. This should be a value greater than zero, the behavior is undefined otherwise.
`maxBatchSize` Type: Integer Default: `50`	Number of maximum events in a batch call.
`maxRetries` Type: Integer Default: `3`	Maximum number of consecutive flush attempts before the entire queue is dropped to avoid infinite retries against a permanently-broken backend (e.g. wrong API key, exhausted quota, deterministic 5xx). Increments on every retriable failure including HTTP 413 cap halving; resets on a successful 2xx response.
`captureApplicationLifecycleEvents` Type: Boolean Default: `true`	Whether the posthog client should automatically make a capture call for application lifecycle events, such as "Application Installed", "Application Updated" and "Application Opened".
`captureScreenViews` Type: Boolean Default: `true`	Whether the posthog client should automatically make a screen call when a view controller is added to a view hierarchy. Because the underlying implementation uses method swizzling, we recommend initializing the posthog client as early as possible (before any screens are displayed), ideally during the Application delegate's applicationDidFinishLaunching method.
`enableSwizzling` Type: Boolean Default: `true`	Enable method swizzling for SDK functionality that depends on it. When disabled, functionality that requires swizzling (like autocapture, screen views, session replay, surveys) will not be installed.
`captureElementInteractions` Type: Boolean Default: `false`	(UIKit only) Whether the posthog client should automatically make a capture call when the user interacts with an element in a screen.
`rageClickConfig` Type: Object Default: `.init()`	(iOS/macCatalyst, UIKit) Rage click detection configuration. Includes `enabled` (default `true`), `minimumTapCount` (default `3`), `thresholdPoints` (default `30`), and `timeoutInterval` (default `1.0`). Works independently of `captureElementInteractions`. Available in version 3.51.0+.
`sendFeatureFlagEvent` Type: Boolean Default: `true`	Send a `$feature_flag_called` event when a feature flag is used automatically.
`preloadFeatureFlags` Type: Boolean Default: `true`	Preload feature flags automatically.
`evaluationContexts` Type: Array of Strings Default: `undefined`	Evaluation context tags that constrain which feature flags are evaluated. When set, only flags with matching evaluation context tags (or no evaluation context tags) will be returned. See evaluation contexts documentation for more details. Available in version 3.38.0+. The legacy parameter `evaluationEnvironments` (version 3.33.0+) is also supported for backward compatibility.
`debug` Type: Boolean Default: `false`	Logs the SDK messages to the Xcode console.
`optOut` Type: Boolean Default: `false`	Prevents capturing any data if enabled.
`getAnonymousId` Type: Function Default: `undefined`	Hook that allows for modification of the default mechanism for generating anonymous id (which as of now is just random UUID v7).
`dataMode` Type: Enum Default: `.any`	Controls when queued data is flushed. Use `.wifi` to flush only on Wi-Fi; `.cellular` is a legacy value and behaves like `.any`.
`personProfiles` Type: Enum Default: `.identifiedOnly`	Determines the behavior for processing user profiles.
`setDefaultPersonProperties` Type: Boolean Default: `true`	Automatically set common device and app properties (such as `$app_version`, `$os_name`, and `$device_type`) as person properties for feature flag evaluation. See property overrides for more details.
`sessionReplay` Type: Boolean Default: `false`	Enable Recording of Session Replays.
`sessionReplayConfig` Type: Object Default: `.init()`	Session Replay configuration. See Session Replay installation for more details.
`tracingHeaders` Type: Array of Strings Default: `nil`	Exact hostnames that should receive PostHog tracing headers when the SDK instruments `URLSession` requests.
`errorTrackingConfig` Type: Object Default: `.init()`	Error Tracking configuration. See the error tracking docs for more details.
`logs` Type: Object Default: `.init()`	Structured Logs configuration. See Logs installation for more details.
`surveysConfig` Type: Object Default: `.init()`	Surveys configuration, including custom survey delegates and display language overrides.
`urlSessionConfiguration` Type: URLSessionConfiguration Default: `.default`	Custom `URLSessionConfiguration` used by the SDK for PostHog API requests.
`appGroupIdentifier` Type: String Default: `nil`	The identifier of the App Group that should be used to store shared analytics data. PostHog will try to get the physical location of the App Group's shared container, otherwise fallback to the default location.
`reuseAnonymousId` Type: Boolean Default: `false`	Whether the SDK should reuse the anonymous Id between user changes. When enabled, a single Id will be used for all anonymous users on this device.
`surveys` Type: Boolean Default: `true`	Enable Surveys.
`setBeforeSend` Type: Function Default: `undefined`	Hook that allows for amending, sampling, or dropping events before they are sent to PostHog.
`bootstrap` Type: `PostHogBootstrapConfig` Default: `nil`	Seeds identity (`distinctId`, `isIdentifiedId`) and feature-flag state (`featureFlags`, `featureFlagPayloads`) before the first `/flags` response. Bootstrapped identity applies to the first session; only enabled flags are served, until the first `/flags` response replaces them. See SDK bootstrapping.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs Python, Needs Node.js

Security

What our scanner noticed· Low risk

Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by

PostHog

Publisher

PostHog (Official)

Source

PostHog/skills · skills/omnibus/instrument-integration · commit a5d30e7

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by PostHog or PostHog.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download instrument-integration.zip