posthog/instrument-logs
skills/instrument-logs/SKILL.md
Add PostHog log capture to track application logs. Use after implementing features or reviewing PRs to ensure meaningful log events are captured with structured properties. Also handles initial OTLP exporter setup if not yet configured.
$ install --global
skillsauthnpx skillsauth add posthog/ai-plugin instrument-logsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 5, 2026, 6:02 AM339.7s17 files scanned
SKILL.md
- name:
- instrument-logs
- description:
- >-
- author:
- PostHog
Add PostHog log capture
Use this skill to add PostHog log capture for new or changed code. Use it after implementing features or reviewing PRs to ensure meaningful log events are captured with structured properties. If PostHog log export is not yet configured, this skill also covers initial OTLP exporter setup. Supports any platform or language.
Supported platforms: Next.js, Node.js, Python, Go, Java, Datadog, Android, React Native, iOS, and any language via OpenTelemetry.
Instructions
Follow these steps IN ORDER:
STEP 1: Analyze the codebase and detect the platform.
- Detect the language, framework, and existing logging setup.
- Look for dependency files and project files (package.json, Podfile, Package.swift, requirements.txt, go.mod, pom.xml, etc.).
- Look for log libraries (winston, pino, logging module, logrus, log4j, serilog, os_log, Logger, etc.).
- Look for lockfiles (pnpm-lock.yaml, package-lock.json, yarn.lock, bun.lockb, go.sum, Podfile.lock, Package.resolved, etc.) to determine the package manager.
- Check for existing PostHog log export setup. If the OTLP exporter is already configured, skip to STEP 5 to add log capture for new code.
STEP 2: Research log capture. (Skip if PostHog log export is already configured.) 2.1. Find the reference file below that matches the detected platform — it is the source of truth for OTLP exporter configuration and integration with existing logging. Read it now. 2.2. If no reference matches, use the "Other Languages" reference as a fallback — it covers the generic OpenTelemetry approach.
STEP 3: Install dependencies. (Skip if PostHog log export is already configured.)
- Install the OpenTelemetry SDK and OTLP exporter packages for the detected platform.
- Do not manually edit dependency files — use the package manager's install command.
- Always install packages as a background task. Don't await completion; proceed with other work immediately.
STEP 4: Configure the OTLP exporter. (Skip if PostHog log export is already configured.)
- PostHog logs use the OpenTelemetry protocol. Set up an OTLP exporter pointed at PostHog's ingest endpoint.
- For SDK-native log support such as Android, React Native, and iOS, follow the platform reference instead of adding a separate OTLP exporter.
- Follow the platform-specific reference for the exact configuration.
STEP 5: Integrate with existing logging.
- Add the PostHog log exporter alongside existing logging. Don't replace existing log handlers or outputs.
- Do not alter the fundamental architecture of existing files. Make additions minimal and targeted.
- You must read a file immediately before attempting to write it.
STEP 6: Add structured properties.
- Ensure logs include structured key-value properties for filtering and search in PostHog.
- Prefer structured log formats with key-value properties over plain text messages.
STEP 7: 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 API key is missing, use the PostHog MCP server's
projects-gettool to retrieve the project'sapi_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 API key instead. - For the PostHog host URL, use
https://us.i.posthog.comfor US Cloud orhttps://eu.i.posthog.comfor EU Cloud. - For the OpenTelemetry endpoint, use
https://us.i.posthog.com/v1(US) orhttps://eu.i.posthog.com/v1(EU). - Write these values to the appropriate env file using the framework's naming convention.
- Reference these environment variables in code instead of hardcoding them.
Reference files
references/nextjs.md- Next.js logs installation - docsreferences/nodejs.md- Node.js logs installation - docsreferences/python.md- Python logs installation - docsreferences/go.md- Go logs installation - docsreferences/java.md- Java logs installation - docsreferences/datadog.md- Datadog logs installation - docsreferences/android.md- Android logs installation - docsreferences/react-native.md- React native logs installation - docsreferences/ios.md- Ios logs installation - docsreferences/other.md- Other languages logs installation - docsreferences/start-here.md- Getting started with logs - docsreferences/search.md- Search logs - docsreferences/best-practices.md- Logging best practices - docsreferences/troubleshooting.md- Logs troubleshooting - docsreferences/link-session-replay.md- Link session replay - docsreferences/debug-logs-mcp.md- Debug logs with mcp - docs
Each platform reference contains specific OTLP configuration, SDK setup, and integration patterns. Find the one matching the user's stack.
Key principles
- Environment variables: Always use environment variables for PostHog keys and OpenTelemetry endpoints. Never hardcode them.
- Minimal changes: Add log export alongside existing logging. Don't replace or restructure existing logging code.
- OpenTelemetry: PostHog logs use the OpenTelemetry protocol. Configure an OTLP exporter pointed at PostHog's ingest endpoint unless the platform SDK provides native log capture.
- SDK-native logs: For Android, React Native, and iOS, use the SDK logger/capture APIs from the platform reference instead of adding a separate OTLP exporter.
- Structured logging: Prefer structured log formats with key-value properties over plain text messages.
Related Skills
posthog/signals-scout-web-analytics
tools
VerifiedTrustedCommunity
Focused Signals scout for PostHog projects with web traffic. Watches the acquisition and site-health layer the web analytics product reports on: per-channel session volume diverging from the site's own rhythm (an acquisition source silently collapsing or surging), attribution breakage (paid/campaign traffic reclassifying into Direct or Unknown when tagging breaks), landing pages that break (bounce-rate steps, 404 spikes, entry-path cliffs), and page-performance regressions (web vitals p75 steps). Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet.
51SKILL.mdUpdated Jun 11, 2026
posthog/signals-scout-session-replay
tools
VerifiedTrustedCommunity
Focused Signals scout for PostHog projects using session replay. Watches two promises the replay product makes: that sessions are actually being recorded (capture integrity — recording volume vanishing while site traffic doesn't), and that the friction evidence inside recordings gets seen (rage-click / dead-click clusters concentrating on a page or element, error-after-interaction cohorts, recurring replay vision themes nobody aggregates). Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet.
51SKILL.mdUpdated Jun 11, 2026
posthog/signals-scout-health-checks
tools
VerifiedTrustedCommunity
Focused Signals scout for PostHog setup health. Reads the project's active health issues — the deterministic findings of PostHog's own health checks (no live events, outdated SDKs, missing reverse proxy, absent web vitals, ingestion warnings, failing data-warehouse models, and more) — and decides which are genuinely worth surfacing. Unlike a one-signal-per-issue push, it bundles kind-clusters into a single finding, weights by real blast radius (cross-referencing actual event volume and reach), and prioritizes issues an agent can resolve via the MCP. Emits only above the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet — no dependencies on other skills.
51SKILL.mdUpdated Jun 11, 2026
posthog/signals-scout-feature-flags
tools
VerifiedTrustedCommunity
Focused Signals scout for PostHog projects using feature flags. Watches the flag roster and the `$feature_flag_called` evaluation stream for contradictions between a flag's configured state and its real traffic: evaluation cliffs on healthy flags, ghost flags (code calling keys that no longer exist), response-distribution shifts with no corresponding flag edit, and flag debt (stale, fully-rolled-out, or dead flags still burning evaluations). Emits findings only when they clear the confidence bar; otherwise writes durable memory and closes out empty. Self-contained peer in the signals-scout-* fleet — no dependencies on other skills.
51SKILL.mdUpdated Jun 11, 2026