New to Claude Skills? Learn how to install them →

posthog on GitHub

Porting PostHog/code PRs

Free

Easily port PRs from PostHog/code to the monorepo.

by posthog37.6k stars on posthog/posthog
2 views
Updated Aug 11, 2026
Get this skill

Free · Opens the source repo

What Porting PostHog/code PRs does

The Porting PostHog/code PRs skill is designed to facilitate the migration of pull requests from the PostHog/code repository to the PostHog monorepo after a significant structural change. When the main branch of PostHog/code is frozen post-import, this skill allows developers to recreate open pull requests in the new monorepo structure while preserving the original commit authorship. This is particularly useful for developers who have ongoing contributions that need to be integrated into the new codebase without losing attribution.

To use the skill, you begin by verifying the author's GitHub login and enumerating their open pull requests. The skill intelligently assesses which pull requests can be ported, skipped, or flagged for further review based on the state of the code in the monorepo. It ensures that only relevant changes are migrated, avoiding duplicates and maintaining a clean history. Each ported pull request is handled in a systematic way, applying patches with the correct directory structure and resolving any conflicts that arise during the process.

The skill also includes mechanisms for verifying the integrity of the migrated code, running necessary tests, and ensuring that the pull requests adhere to the monorepo's contribution guidelines. By automating these steps, developers can save time and reduce the risk of errors that may occur during manual migrations. This tool is particularly beneficial for teams that need to maintain a consistent workflow during significant changes to their codebase, ensuring that contributions are not lost in the transition.

Overall, the Porting PostHog/code PRs skill is an essential tool for developers working within the PostHog ecosystem, streamlining the process of integrating ongoing contributions into a new monorepo structure while ensuring proper attribution and compliance with project standards.

When to use it

Use this skill when you need to port open pull requests from PostHog/code to the PostHog monorepo after the desktop import.

When not to use it

This skill is not suitable for porting merged pull requests or for cases where no pull requests are open on PostHog/code.

What you can build with it

Porting Multiple PRs

When a developer has several open pull requests on PostHog/code, this skill can automate the porting process, ensuring all relevant changes are migrated efficiently.

Maintaining Author Attribution

This skill preserves the original authorship of commits during the porting process, which is crucial for maintaining contribution records in the monorepo.

Handling Conflicts in PRs

If a pull request encounters conflicts with existing code in the monorepo, this skill provides guidance on how to resolve those conflicts effectively.

How to install Porting PostHog/code PRs

View source

1. Install with the skills CLI

npx skills add posthog/posthog/porting-code-prs --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by posthog

Porting PostHog/code PRs to the monorepo

PostHog/code's main is frozen after the desktop import. The tree lives at products/desktop/ as a verbatim copy of the source at a pinned SHA, so open PRs on PostHog/code can no longer land there and are remade as monorepo PRs instead. products/desktop/MIGRATION.md is the contract for the import: its pinned SHA, drift list and workflow mapping table are authoritative over anything restated here. Read it before resolving any conflict.

Path mapping: <path> in PostHog/code becomes products/desktop/<path>. The one exception is .github/, which was not imported: source workflows were transformed into root .github/workflows/desktop-*.yml files per the mapping table and transform rules in MIGRATION.md.

Scope the sweep

Resolve the author's GitHub login first (gh api user --jq .login when it is the requester). Then enumerate:

gh pr list --repo PostHog/code --author <login> --state open \
  --json number,title,isDraft,headRefName,url,body

For each PR decide: port, skip or flag.

  • Skip a PR whose change already exists in products/desktop/ (superseded, or landed upstream and arrived via a resync). Check the tree, not just the PR state.
  • Never port a PR that was merged into PostHog/code. Merged-after-pin changes arrive through the resync protocol in MIGRATION.md, and porting them too would duplicate the diff.
  • When source PRs stack on each other, port in dependency order and stack the monorepo branches the same way.

The skill works the same for a single PR; the sweep is just the loop.

Port one PR

Work on a branch off fresh master, one monorepo PR per source PR. Reusing the source head branch name keeps the pair easy to correlate.

  1. Fetch the patch series, plus the source objects the 3-way fallback needs:
PATCH=$(mktemp)
gh pr diff <N> --repo PostHog/code --patch > "$PATCH"
git fetch https://github.com/PostHog/code.git refs/pull/<N>/head
  1. Apply with authorship preserved:
git am -3 --empty=drop --directory=products/desktop/ \
  --exclude='products/desktop/.github/*' \
  --exclude='products/desktop/pnpm-lock.yaml' \
  --exclude='products/desktop/packages/agent/pnpm-lock.yaml' \
  "$PATCH"

--exclude matches after --directory is prepended, so the patterns carry the products/desktop/ prefix. git am keeps each commit's original author and message; the commits are created and signed by you, which satisfies the signed-commit ruleset while crediting the source author. On conflict, resolve and git am --continue; git am --abort resets. The 3-way merge only works because step 1 fetched the source PR's objects.

  1. Re-derive the excluded paths when the PR touched them:
  • .github/**: look the workflow up in MIGRATION.md's mapping table. If it is in the dropped table the change is moot. Otherwise re-apply the source change to the ported root desktop-*.yml by following the transform rules, and invoke /authoring-ci-workflows before editing.
  • Lockfiles: the monorepo copies carry local override pins from the drift list, so source lockfile hunks silently undo security pins. Land the package.json change, then regenerate from products/desktop/ with pnpm install --lockfile-only, minding the minimumReleaseAge notes in MIGRATION.md.
  1. Treat conflicts in drift-listed files (local security patches, pnpm-workspace.yaml overrides) as intentional monorepo divergence: keep the monorepo side and re-apply the PR's intent on top of it.

  2. Verify from products/desktop/: pnpm install --frozen-lockfile, pnpm typecheck and pnpm --filter <pkg> test for the packages the PR touches. The desktop CI suite runs on the monorepo PR itself.

Open the monorepo PR

  • Title: keep the source title when it fits the monorepo's conventional-commit format; otherwise fix it up (desktop scope).
  • Body: use .github/pull_request_template.md. Carry the original description over, rewriting bare #N references as PostHog/code#N so they do not resolve to unrelated monorepo PRs. State "Ports PostHog/code#N" so the pair is linked.
  • Preserve draft state and assign the original author.
  • Do not close or comment on the source PR without the author's say-so. The clean sequence is: link the monorepo PR from the source PR, then close the source once the port merges.

Report

End a sweep with one line per source PR: ported to #X, skipped (why) or flagged for a human (why). Never silently drop a PR from the sweep.

Frequently asked questions about Porting PostHog/code PRs

Similar skills