Back to Skills

mcore-split-pr

Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.

2,779stars322forksUpdated 8/4/2026

Security Assessment

Safe(92/100)
Security Score92/100

About mcore-split-pr

The mcore-split-pr skill helps split a large Megatron-LM pull request into multiple smaller PRs, each touching the fewest possible CODEOWNERS reviewer groups. It solves a concrete review-burden problem: a PR spanning core, examples, tools, and training directories pulls in many reviewer groups, slowing merges, whereas a PR scoped to a single directory needs only that directory's reviewers.

The workflow has three phases. First it analyzes the PR by fetching its details and diff stat with the gh CLI, parsing .github/CODEOWNERS to map file patterns to owner groups, and counting the distinct reviewer groups the PR currently requires. Second it proposes a split that clusters files by their CODEOWNERS groups, keeps tests with the production code they validate, flags cross-PR dependencies (for example symbols renamed in one PR that another depends on), ensures each resulting PR is independently mergeable, and presents the plan as a table for user approval. Third, only after approval, it executes by creating branches from the correct base, applying file-scoped diffs with git apply, committing, and pushing to the user's fork. It always creates PRs as drafts, never pushes directly to upstream, confirms before any force-push, and credits the original author when the current user is not the PR author.

Target users are Megatron-LM contributors and maintainers dealing with sprawling PRs who want to reduce the number of reviewer groups per PR while keeping each split independently reviewable and mergeable. It is user-invocable with a PR URL or number as its argument.

FAQ

What problem does splitting a PR solve?

It minimizes the number of CODEOWNERS reviewer groups required per PR, reducing review burden. Each resulting PR must still be independently mergeable and reviewable.

Does it push directly to the main repository?

No. It always creates PRs as drafts and pushes to the user's fork, never directly to upstream, and it confirms with the user before any force-push that narrows the original PR.

How are tests handled during a split?

Test files travel with the production code they validate. The skill explicitly avoids splitting tests into a separate PR just to reduce reviewer groups.

What happens when one split PR depends on another?

It calls out the dependency explicitly and places backward-compatible aliases, re-exports, or shims in the first PR so subsequent PRs can depend on them, and notes the required merge order.

What does it need to run?

The gh CLI authenticated for the repository, a local checkout with an upstream remote, and a user fork to push branches to. It waits for user approval before executing the split.

All Files

5 files
SKILL.md4.4 KB
View
skill.oms.sig4.5 KB
View
BENCHMARK.md2.7 KB
View
evals/evals.json0.0 KB
View
skill-card.md2.4 KB
View

Install mcore-split-pr

Download and extract the skill files to your .claude/skills/ directory.

Quick Setup:

  1. Copy the skill folder to .claude/skills/
  2. Claude will automatically detect and use the skill

Repository

nvidia/skills