Agent skill · software engineering · jeremylongshore
posthog-upgrade-migration
Upgrade PostHog SDKs through release-note review, configuration-default comparison, focused tests, canary evidence, and rollback. Use when changing a PostHog package version or defaults date. Trigger with "upgrade PostHog SDK", "PostHog breaking change", or "PostHog version migration".
Why this skill is useful
Provides a systematic upgrade procedure and breaking change detection for PostHog SDKs that the AI wouldn't reliably generate on its own.
What it needs
Requires git, npm installed locally. About 4k tokens when loaded. Last updated 2026-08-07. 2,604 stars on the source repository.
What this skill does
PostHog Upgrade & Migration Overview Upgrade PostHog SDKs from the versions actually locked by the target project to explicit target versions. Build the change list from current release notes and type surfaces, then prove capture, identity, consent, flags, flushing, and rollback behavior in the environments the application uses. Prerequisites PostHog SDK currently installed Git for branching Test suite covering PostHog integration Staging environment for validation Instructions Tool discipline Use Read and Grep to inspect manifests, lockfiles, initialization, and release-sensitive options before proposing changes. Use Write only for a new, explicitly requested artifact inside the target project. Use Edit for minimal changes to existing project files after the evidence pass. Use npm, npx, pip, and git Bash commands only in the selected project and preserve the recorded rollback versions. Step 1: Audit Current Versions Step 2: Build the Version Delta Read every release note between the locked and target versions, plus the current SDK reference for each configured option. Produce a small evidence table with: package, locked version, target version, runtime requirement, changed default or API, affected source locations, required test, and rollback version. Pay particular attention to browser defaults dates, autocapture and persistence, consent, replay, server flush semantics, feature-flag evaluation, and whether events attach flag properties. Do not infer compatibility from a major-version number or a remembered migration note. Step 3: Upgrade Procedure Step 4: Search for Deprecated Patterns Step 5: Validate in Staging Step 6: Rollback if Needed Upgrade Evidence Attach the completed version-delta table, dependency and lockfile diff, focused test output, staging event/flag evidence, canary window, observed ingestion warnings, and exact rollback commands. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills jeremylongshore/posthog-upgrade-migration