Lar

Skill

Revisão de código

mcore-split-pr

nvidia/skills

Divida um PR em vários PRs para reduzir o número de grupos de revisores CODEOWNERS necessários.

...Expandir tudo

Tempo atualizado 26 de Agosto de 2026

# automation # github # code-review # git # pull-request # Code ReviewGit & Version ControlProductivity & Workflow

Sobre o mcore-split-pr

A habilidade mcore-split-pr ajuda a dividir um grande pedido de pull request do Megatron-LM em vários PRs menores, cada um envolvendo o menor número possível de grupos de revisores CODEOWNERS. Ela resolve um problema concreto de sobrecarga de revisões: um PR que abrange o código principal, exemplos, ferramentas e diretórios de treinamento atrai muitos grupos de revisores, atrasando as fusões, enquanto um PR limitado a um único diretório precisa apenas dos revisores desse diretório.

O fluxo de trabalho possui três fases. Primeiro, ele analisa o PR coletando seus detalhes e estatísticas de diferenças por meio do gh CLI, interpretando o arquivo .github/CODEOWNERS para associar padrões de arquivos a grupos de proprietários e contando os grupos de revisores distintos necessários atualmente. Em seguida, propõe uma divisão que agrupa os arquivos de acordo com seus grupos CODEOWNERS, mantém os testes junto ao código de produção que eles validam, identifica dependências entre PRs (por exemplo, símbolos renomeados em um PR dos quais outro depende), garante que cada PR resultante possa ser fusionado de forma independente e apresenta o plano em formato de tabela para aprovação do usuário. Por fim, somente após a aprovação, ele executa a divisão criando ramificações a partir da base correta, aplicando diferenças específicas para cada arquivo por meio de git apply, fazendo commits e enviando os resultados para o fork do usuário. Ele sempre cria os PRs como rascunhos, nunca os envia diretamente para o repositório principal, confirma com o usuário antes de realizar qualquer force-push que reduza o escopo do PR original e dá crédito ao autor original quando o usuário atual não for o criador do PR.

Os usuários-alvo são colaboradores e mantenedores do Megatron-LM que lidam com PRs extensos e desejam reduzir o número de grupos de revisores por PR, mantendo ao mesmo tempo a possibilidade de revisão e fusão independentes para cada parte dividida. A ferramenta pode ser acionada pelo usuário informando o URL ou número do PR como parâmetro.

Perguntas Frequentes

Qual problema a divisão de um PR resolve?

Ela minimiza o número de grupos de revisores CODEOWNERS necessários por PR, reduzindo assim a carga de revisão. Cada PR resultante ainda precisa ser capaz de ser fusionado e revisado de forma independente.

Ele envia os arquivos diretamente para o repositório principal?

Não. Ele sempre cria os PRs como rascunhos e os envia para o fork do usuário, nunca diretamente para o repositório principal, além de confirmar com o usuário antes de realizar qualquer force-push que reduza o escopo do PR original.

Como os testes são tratados durante a divisão?

Os arquivos de teste são enviados juntamente com o código de produção que eles validam. A ferramenta evita explicitamente dividir os testes em um PR separado apenas para diminuir o número de grupos de revisores.

O que acontece quando um PR dividido depende de outro?

Ela indica explicitamente essa dependência e inclui aliases compatíveis com versões anteriores, reexportações ou substitutos no primeiro PR, de modo que os PRs subsequentes possam depender deles, além de indicar a ordem necessária para a fusão.

O que é necessário para que ela funcione?

É preciso ter o gh CLI autenticado no repositório, um checkout local com o repositório upstream configurado e um fork do usuário para onde os branches serão enviados. A ferramenta aguarda a aprovação do usuário antes de executar a divisão.

Todos os Arquivos

5 arquivosSKILL.md4,4 KBVisualizarskill.oms.sig4,5 KBVisualizarBENCHMARK.md2,7 KBVisualizarevals/evals.json0,0 KBVisualizarskill-card.md2,4 KBVisualizar

Ver no GitHub

Split a large pull request into multiple smaller PRs, where each PR touchesthe fewest possible CODEOWNERS reviewer groups. The goal is to reduce reviewburden: a PR that only touches megatron/core/ needs only the core reviewers,while a PR that also touches examples/, tools/, and megatron/training/pulls in many additional groups.

Answer-First Constraints

For split-planning questions, lead with these constraints before the fullworkflow:

Minimize CODEOWNERS reviewer groups per PR, but each resulting PR must stillbe independently mergeable and reviewable.
Tests travel with the production code they validate; do not split tests into aseparate PR just to reduce reviewer groups.
If PR B depends on symbols renamed in PR A, call out the dependency and putbackward-compatible aliases, re-exports, or shims in PR A when needed.
Wait for user approval before execution.
Execution creates draft PRs from the right base, applies file-scoped diffswith git diff upstream/main..<source-branch> -- <paths> | git apply, pushesto the user's fork, and never pushes directly to upstream.

Workflow

1. Analyze the PR

Fetch the PR details: gh pr view <number> --repo NVIDIA/Megatron-LM --json title,body,headRefName,author and gh pr diff <number> --repo NVIDIA/Megatron-LM --stat. Also determine the current GitHub user with gh api user --jq .login.
Parse .github/CODEOWNERS to build a mapping from file path patterns to owner groups.
For each changed file in the PR, determine which CODEOWNERS groups would be required to review it.
Build a summary table grouped by CODEOWNERS group, showing which files pull in which groups.
Count the total number of distinct reviewer groups the PR currently requires.

2. Propose a split that minimizes reviewer groups per PR

The primary optimization goal: minimize the number of CODEOWNERS reviewer groups required for each resulting PR.

Strategy:

Cluster files by their CODEOWNERS groups. Files owned by the same set of groups naturally belong together.
Identify the largest cluster — this becomes the first (and usually largest) PR.
Remaining files form one or more additional PRs, each ideally requiring only one or two reviewer groups.
If a split creates a dependency (e.g., PR B uses symbols renamed in PR A), the dependent PR must be merged after the first. Note this explicitly.
Each PR must be independently mergeable to main — no broken imports, no missing symbols. Backward-compatible aliases and re-export stubs in the first PR can make this possible.

Present the proposed split as a table:

PR name/description
Files included
CODEOWNERS groups required
Dependencies on other PRs (if any)

Wait for user approval before proceeding.

3. Execute the split (after user approval)

For each new PR:

Create a new branch from the appropriate base (main, or a dependency PR's branch).
Extract the relevant changes: git diff upstream/main..<source-branch> -- <file paths> | git apply.
Stage, commit with a clear message, and push to the user's fork.
Create the PR as a draft (per repo contributing guidelines).
If the original PR needs to be narrowed in scope, confirm with the user before force-pushing.
Report all PR URLs when done.

Important guidelines

Always create PRs as drafts and push to the user's fork, never directly to upstream.
Backward-compatible changes (aliases, re-exports, deprecation shims) should go in the first PR so subsequent PRs can depend on them.
Test files should go with the production code they test, not in a separate PR.
Prefer a single clean commit per split PR over replaying the original commit history.
If a file is hard to categorize (e.g., it touches two groups), ask the user which PR it should go in.
If the current GitHub user is not the author of the original PR, each new PR's description must explicitly credit the original author (e.g., "Original changes by @ in #").