[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7BYD2MH9MHCDK3P4AM5D3H5":3,"skill-same:01M7BYD2MH9MHCDK3P4AM5D3H5":43},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":23,"commitSha":24,"skillDirectory":25,"forksCount":13,"repositoryHtmlUrl":26,"repositoryHomepageUrl":6,"ownerHtmlUrl":27,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":28,"install":29,"resources":42},"01M7BYD2MH9MHCDK3P4AM5D3H5","gk-dev-mcore-split-pr",null,"Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.","makeyzhang-cpu\u002Fgeekclaw","makeyzhang-cpu","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F282184316?v=4","01M7BY92NE8R5TAVDAV2CTBGHV","01M7BY92P6TYAA1XX1E7XCX7GS",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmakeyzhang-cpu\u002Fgeekclaw\u002Fblob\u002Fmain\u002Fcrates\u002Fbackend\u002Fnomifun-app\u002Fassets\u002Fbuiltin-skills\u002Fgk-dev-mcore-split-pr\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: gk-dev-mcore-split-pr\ndescription: \"Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.\"\n---\n\n# mcore-split-pr\n\n# Split PR by CODEOWNERS Groups\n\nSplit a large pull request into multiple smaller PRs, where each PR touches\nthe fewest possible CODEOWNERS reviewer groups. The goal is to reduce review\nburden: a PR that only touches `megatron\u002Fcore\u002F` needs only the core reviewers,\nwhile a PR that also touches `examples\u002F`, `tools\u002F`, and `megatron\u002Ftraining\u002F`\npulls in many additional groups.\n\n## Answer-First Constraints\n\nFor split-planning questions, lead with these constraints before the full\nworkflow:\n\n- Minimize CODEOWNERS reviewer groups per PR, but each resulting PR must still\n  be independently mergeable and reviewable.\n- Tests travel with the production code they validate; do not split tests into a\n  separate PR just to reduce reviewer groups.\n- If PR B depends on symbols renamed in PR A, call out the dependency and put\n  backward-compatible aliases, re-exports, or shims in PR A when needed.\n- Wait for user approval before execution.\n- Execution creates draft PRs from the right base, applies file-scoped diffs\n  with `git diff upstream\u002Fmain..\u003Csource-branch> -- \u003Cpaths> | git apply`, pushes\n  to the user's fork, and never pushes directly to upstream.\n\n## Workflow\n\n### 1. Analyze the PR\n\n1. Fetch the PR details: `gh pr view \u003Cnumber> --repo NVIDIA\u002FMegatron-LM --json title,body,headRefName,author` and `gh pr diff \u003Cnumber> --repo NVIDIA\u002FMegatron-LM --stat`. Also determine the current GitHub user with `gh api user --jq .login`.\n2. Parse `.github\u002FCODEOWNERS` to build a mapping from file path patterns to owner groups.\n3. For each changed file in the PR, determine which CODEOWNERS groups would be required to review it.\n4. Build a summary table grouped by CODEOWNERS group, showing which files pull in which groups.\n5. Count the total number of distinct reviewer groups the PR currently requires.\n\n### 2. Propose a split that minimizes reviewer groups per PR\n\nThe primary optimization goal: **minimize the number of CODEOWNERS reviewer groups required for each resulting PR**.\n\nStrategy:\n1. Cluster files by their CODEOWNERS groups. Files owned by the same set of groups naturally belong together.\n2. Identify the largest cluster — this becomes the first (and usually largest) PR.\n3. Remaining files form one or more additional PRs, each ideally requiring only one or two reviewer groups.\n4. 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.\n5. 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.\n\nPresent the proposed split as a table:\n- PR name\u002Fdescription\n- Files included\n- CODEOWNERS groups required\n- Dependencies on other PRs (if any)\n\nWait for user approval before proceeding.\n\n### 3. Execute the split (after user approval)\n\nFor each new PR:\n1. Create a new branch from the appropriate base (`main`, or a dependency PR's branch).\n2. Extract the relevant changes: `git diff upstream\u002Fmain..\u003Csource-branch> -- \u003Cfile paths> | git apply`.\n3. Stage, commit with a clear message, and push to the user's fork.\n4. Create the PR as a **draft** (per repo contributing guidelines).\n5. If the original PR needs to be narrowed in scope, confirm with the user before force-pushing.\n6. Report all PR URLs when done.\n\n## Important guidelines\n\n- Always create PRs as **drafts** and push to the user's fork, never directly to upstream.\n- Backward-compatible changes (aliases, re-exports, deprecation shims) should go in the first PR so subsequent PRs can depend on them.\n- Test files should go with the production code they test, not in a separate PR.\n- Prefer a single clean commit per split PR over replaying the original commit history.\n- If a file is hard to categorize (e.g., it touches two groups), ask the user which PR it should go in.\n- 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 @\u003Cauthor> in #\u003Cnumber>\").\n","# mcore-split-pr\n\n# Split PR by CODEOWNERS Groups\n\nSplit a large pull request into multiple smaller PRs, where each PR touches\nthe fewest possible CODEOWNERS reviewer groups. The goal is to reduce review\nburden: a PR that only touches `megatron\u002Fcore\u002F` needs only the core reviewers,\nwhile a PR that also touches `examples\u002F`, `tools\u002F`, and `megatron\u002Ftraining\u002F`\npulls in many additional groups.\n\n## Answer-First Constraints\n\nFor split-planning questions, lead with these constraints before the full\nworkflow:\n\n- Minimize CODEOWNERS reviewer groups per PR, but each resulting PR must still\n  be independently mergeable and reviewable.\n- Tests travel with the production code they validate; do not split tests into a\n  separate PR just to reduce reviewer groups.\n- If PR B depends on symbols renamed in PR A, call out the dependency and put\n  backward-compatible aliases, re-exports, or shims in PR A when needed.\n- Wait for user approval before execution.\n- Execution creates draft PRs from the right base, applies file-scoped diffs\n  with `git diff upstream\u002Fmain..\u003Csource-branch> -- \u003Cpaths> | git apply`, pushes\n  to the user's fork, and never pushes directly to upstream.\n\n## Workflow\n\n### 1. Analyze the PR\n\n1. Fetch the PR details: `gh pr view \u003Cnumber> --repo NVIDIA\u002FMegatron-LM --json title,body,headRefName,author` and `gh pr diff \u003Cnumber> --repo NVIDIA\u002FMegatron-LM --stat`. Also determine the current GitHub user with `gh api user --jq .login`.\n2. Parse `.github\u002FCODEOWNERS` to build a mapping from file path patterns to owner groups.\n3. For each changed file in the PR, determine which CODEOWNERS groups would be required to review it.\n4. Build a summary table grouped by CODEOWNERS group, showing which files pull in which groups.\n5. Count the total number of distinct reviewer groups the PR currently requires.\n\n### 2. Propose a split that minimizes reviewer groups per PR\n\nThe primary optimization goal: **minimize the number of CODEOWNERS reviewer groups required for each resulting PR**.\n\nStrategy:\n1. Cluster files by their CODEOWNERS groups. Files owned by the same set of groups naturally belong together.\n2. Identify the largest cluster — this becomes the first (and usually largest) PR.\n3. Remaining files form one or more additional PRs, each ideally requiring only one or two reviewer groups.\n4. 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.\n5. 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.\n\nPresent the proposed split as a table:\n- PR name\u002Fdescription\n- Files included\n- CODEOWNERS groups required\n- Dependencies on other PRs (if any)\n\nWait for user approval before proceeding.\n\n### 3. Execute the split (after user approval)\n\nFor each new PR:\n1. Create a new branch from the appropriate base (`main`, or a dependency PR's branch).\n2. Extract the relevant changes: `git diff upstream\u002Fmain..\u003Csource-branch> -- \u003Cfile paths> | git apply`.\n3. Stage, commit with a clear message, and push to the user's fork.\n4. Create the PR as a **draft** (per repo contributing guidelines).\n5. If the original PR needs to be narrowed in scope, confirm with the user before force-pushing.\n6. Report all PR URLs when done.\n\n## Important guidelines\n\n- Always create PRs as **drafts** and push to the user's fork, never directly to upstream.\n- Backward-compatible changes (aliases, re-exports, deprecation shims) should go in the first PR so subsequent PRs can depend on them.\n- Test files should go with the production code they test, not in a separate PR.\n- Prefer a single clean commit per split PR over replaying the original commit history.\n- If a file is hard to categorize (e.g., it touches two groups), ask the user which PR it should go in.\n- 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 @\u003Cauthor> in #\u003Cnumber>\").\n",{"name":5,"description":7},"main","1f321f8966b6741235f35f79c97c0ffdcffb11ba","crates\u002Fbackend\u002Fnomifun-app\u002Fassets\u002Fbuiltin-skills\u002Fgk-dev-mcore-split-pr","https:\u002F\u002Fgithub.com\u002Fmakeyzhang-cpu\u002Fgeekclaw","https:\u002F\u002Fgithub.com\u002Fmakeyzhang-cpu","2026-11-08 16:23:21",{"source":8,"skillName":5,"commands":30,"prompt":40,"zipAvailable":41},[31,34,37],{"tool":32,"command":33},"npx","npx skills add makeyzhang-cpu\u002Fgeekclaw --skill gk-dev-mcore-split-pr",{"tool":35,"command":36},"bunx","bunx skills add makeyzhang-cpu\u002Fgeekclaw --skill gk-dev-mcore-split-pr",{"tool":38,"command":39},"pnpm","pnpm dlx skills add makeyzhang-cpu\u002Fgeekclaw --skill gk-dev-mcore-split-pr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmakeyzhang-cpu\u002Fgeekclaw\u002Fblob\u002Fmain\u002Fcrates\u002Fbackend\u002Fnomifun-app\u002Fassets\u002Fbuiltin-skills\u002Fgk-dev-mcore-split-pr\u002FSKILL.md",true,[],[44,51,58,65,72,79],{"skillNo":45,"name":46,"nameZh":6,"description":47,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":48,"categories":49,"keywords":50,"publishedAt":18},"01M7BYJ19XV75TDGRGXBFJN1T4","drive-geekclaw","Use to connect to and drive a GeekClaw instance from an external agent (Claude Code \u002F Cursor \u002F any MCP client). Drive its browser \u002F computer \u002F knowledge base \u002F files and manage the platform over MCP or REST, with a per-companion access token (you run AS the bound companion). Use this whenever the user asks to control, automate, or hand work off to \"GeekClaw\", \"their GeekClaw\", \"the desktop companion\", or a running GeekClaw server.","https:\u002F\u002Fgithub.com\u002Fmakeyzhang-cpu\u002Fgeekclaw\u002Fblob\u002Fmain\u002Fdocs\u002Fskills\u002Fdrive-nomifun\u002FSKILL.md",[],[],{"skillNo":52,"name":53,"nameZh":6,"description":54,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":55,"categories":56,"keywords":57,"publishedAt":18},"01M7BYHZBZNHHBX8M87JZ6Y031","example-skill","Fixture skill used by startup_materialize integration tests.","https:\u002F\u002Fgithub.com\u002Fmakeyzhang-cpu\u002Fgeekclaw\u002Fblob\u002Fmain\u002Fcrates\u002Fbackend\u002Fnomifun-extension\u002Ftests\u002Ffixtures\u002Fbuiltin-skills-fixture\u002Fexample-skill\u002FSKILL.md",[],[],{"skillNo":59,"name":60,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":18},"01M7BYHWFXC17GE9SXDK1X3GTD","ui-ux-pro-max","Professional UI\u002FUX design research skill with a bundled searchable database for product patterns, visual styles, color palettes, typography, landing-page structure, dashboard charts, UX practices, and stack guidance. Use when designing, building, reviewing, or improving interfaces.","https:\u002F\u002Fgithub.com\u002Fmakeyzhang-cpu\u002Fgeekclaw\u002Fblob\u002Fmain\u002Fcrates\u002Fbackend\u002Fnomifun-app\u002Fassets\u002Fbuiltin-skills\u002Fui-ux-pro-max\u002FSKILL.md",[],[],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":18},"01M7BYHR24XK92Z2YYQHK2732Y","planning-with-files","Maintain durable task plans, findings, and progress logs in workspace files for long-running or research-heavy work. Use when a task spans many steps or sessions, needs an auditable evidence trail, or risks losing important decisions to context limits. Do not use for short tasks that fit comfortably in the active conversation.","https:\u002F\u002Fgithub.com\u002Fmakeyzhang-cpu\u002Fgeekclaw\u002Fblob\u002Fmain\u002Fcrates\u002Fbackend\u002Fnomifun-app\u002Fassets\u002Fbuiltin-skills\u002Fplanning-with-files\u002FSKILL.md",[],[],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":18},"01M7BYHKQ6A4CNTQB0JXRJ5AXX","officecli","Create, analyze, proofread, and modify Office documents (.docx, .xlsx, .pptx) using the officecli CLI tool. Use when the user wants to create, inspect, check formatting, find issues, add charts, or modify Office documents.","https:\u002F\u002Fgithub.com\u002Fmakeyzhang-cpu\u002Fgeekclaw\u002Fblob\u002Fmain\u002Fcrates\u002Fbackend\u002Fnomifun-app\u002Fassets\u002Fbuiltin-skills\u002Fofficecli\u002FSKILL.md",[],[],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":18},"01M7BYHD30974T2E9FBTJZN3R2","officecli-xlsx","Use this skill any time a .xlsx file is involved -- as input, output, or both. This includes: creating spreadsheets, financial models, dashboards, or trackers; reading, parsing, or extracting data from any .xlsx file; editing, modifying, or updating existing workbooks; working with formulas, charts, pivot tables, or templates; importing CSV\u002FTSV data into Excel format. Trigger whenever the user mentions 'spreadsheet', 'workbook', 'Excel', 'financial model', 'tracker', 'dashboard', or references a .xlsx\u002F.csv filename.","https:\u002F\u002Fgithub.com\u002Fmakeyzhang-cpu\u002Fgeekclaw\u002Fblob\u002Fmain\u002Fcrates\u002Fbackend\u002Fnomifun-app\u002Fassets\u002Fbuiltin-skills\u002Fofficecli-xlsx\u002FSKILL.md",[],[]]