{"owner":"NVIDIA","repo":"Megatron-LM","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md",".cursorrules"],"skills":{"AGENTS.md":"# Repository Guidelines\n\n## Skills\n\nThe `skills/` directory contains structured guides for common tasks (running\ntests, building containers, managing dependencies, submitting SLURM jobs, etc.).\n**Always read the relevant `SKILL.md` before starting any task it covers —\nskills are mandatory context, not optional background reading.**\n\n**Workflow — mandatory order for every task:**\n1. **Pull information first.** Read the commit, PR, error log, file, or\n   whatever artifact the task is about. Do not reason about it yet.\n2. **Select and invoke the skill.** Based on what you just read, identify\n   the relevant skill and invoke it before forming any answer or plan.\n3. **Answer or implement.** Only after the skill is loaded, use its context\n   to reason, diagnose, or write code.\n\nNever skip or reorder these steps. Do not wait for the user to name the right\nskill keyword — infer it from the artifact you read.\n\n## Contributing\n\n### Pull Requests\n\n- All PRs must be created as **drafts**. Use `gh pr create --draft` or the GitHub UI draft option.\n- Never push branches directly to `https://github.com/NVIDIA/Megatron-LM`. You must push your branch to a personal fork (e.g. `https://github.com/<your-username>/Megatron-LM`), then open a PR from the fork's branch against `NVIDIA/Megatron-LM`.\n- Commit PR changes with both `-s` and `-S`: `-s` adds the required\n  `Signed-off-by` trailer, and `-S` signs the commit so copy-pr-bot and `/ok to\ntest` can verify the pushed commit without manually specifying the SHA.\nMegatron Core engineers at NVIDIA should sign using their NVIDIA emails so they\nare automatically added to the right user groups on the internal Slack\nworkspace.\n- Read @docs/developer/contribute.md for the full contribution policy, including code style, commit message conventions, and issue guidelines.\n\n### Code Quality\n\n- After editing imports in any Python files, always run `uv run isort` on those files to fix import order before committing.\n\n### Megatron Core Process Groups\n\n- In `megatron/core` production code, avoid adding new direct reads of global\n  process groups from `parallel_state` (for example,\n  `parallel_state.get_tensor_model_parallel_group()` or directly imported\n  `get_*_group()` helpers). Prefer accepting a `ProcessGroupCollection` or an\n  explicit `torch.distributed.ProcessGroup` from the caller and passing that\n  through.\n- Allowed compatibility points include `megatron/core/parallel_state.py`,\n  `megatron/core/process_groups_config.py`, initialization/bootstrap code that\n  materializes a `ProcessGroupCollection` from MPU globals, tests, docs, and\n  migration fallbacks with an explicit comment.\n- This guidance targets Megatron Core library code. Do not apply it to\n  `megatron/training` or other training-loop code unless the PR explicitly\n  opts into that migration.\n- In reviews, flag new direct `parallel_state.get_*_group()` usage in\n  `megatron/core` unless it is one of the compatibility points above. This is\n  advisory guidance, not a CI gate.\n",".cursorrules":"See CLAUDE.md for all repository guidelines.\n"},"files":{"AGENTS.md":"# Repository Guidelines\n\n## Skills\n\nThe `skills/` directory contains structured guides for common tasks (running\ntests, building containers, managing dependencies, submitting SLURM jobs, etc.).\n**Always read the relevant `SKILL.md` before starting any task it covers —\nskills are mandatory context, not optional background reading.**\n\n**Workflow — mandatory order for every task:**\n1. **Pull information first.** Read the commit, PR, error log, file, or\n   whatever artifact the task is about. Do not reason about it yet.\n2. **Select and invoke the skill.** Based on what you just read, identify\n   the relevant skill and invoke it before forming any answer or plan.\n3. **Answer or implement.** Only after the skill is loaded, use its context\n   to reason, diagnose, or write code.\n\nNever skip or reorder these steps. Do not wait for the user to name the right\nskill keyword — infer it from the artifact you read.\n\n## Contributing\n\n### Pull Requests\n\n- All PRs must be created as **drafts**. Use `gh pr create --draft` or the GitHub UI draft option.\n- Never push branches directly to `https://github.com/NVIDIA/Megatron-LM`. You must push your branch to a personal fork (e.g. `https://github.com/<your-username>/Megatron-LM`), then open a PR from the fork's branch against `NVIDIA/Megatron-LM`.\n- Commit PR changes with both `-s` and `-S`: `-s` adds the required\n  `Signed-off-by` trailer, and `-S` signs the commit so copy-pr-bot and `/ok to\ntest` can verify the pushed commit without manually specifying the SHA.\nMegatron Core engineers at NVIDIA should sign using their NVIDIA emails so they\nare automatically added to the right user groups on the internal Slack\nworkspace.\n- Read @docs/developer/contribute.md for the full contribution policy, including code style, commit message conventions, and issue guidelines.\n\n### Code Quality\n\n- After editing imports in any Python files, always run `uv run isort` on those files to fix import order before committing.\n\n### Megatron Core Process Groups\n\n- In `megatron/core` production code, avoid adding new direct reads of global\n  process groups from `parallel_state` (for example,\n  `parallel_state.get_tensor_model_parallel_group()` or directly imported\n  `get_*_group()` helpers). Prefer accepting a `ProcessGroupCollection` or an\n  explicit `torch.distributed.ProcessGroup` from the caller and passing that\n  through.\n- Allowed compatibility points include `megatron/core/parallel_state.py`,\n  `megatron/core/process_groups_config.py`, initialization/bootstrap code that\n  materializes a `ProcessGroupCollection` from MPU globals, tests, docs, and\n  migration fallbacks with an explicit comment.\n- This guidance targets Megatron Core library code. Do not apply it to\n  `megatron/training` or other training-loop code unless the PR explicitly\n  opts into that migration.\n- In reviews, flag new direct `parallel_state.get_*_group()` usage in\n  `megatron/core` unless it is one of the compatibility points above. This is\n  advisory guidance, not a CI gate.\n",".cursorrules":"See CLAUDE.md for all repository guidelines.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Repository Guidelines\n\n## Skills\n\nThe `skills/` directory contains structured guides for common tasks (running\ntests, building containers, managing dependencies, submitting SLURM jobs, etc.).\n**Always read the relevant `SKILL.md` before starting any task it covers —\nskills are mandatory context, not optional background reading.**\n\n**Workflow — mandatory order for every task:**\n1. **Pull information first.** Read the commit, PR, error log, file, or\n   whatever artifact the task is about. Do not reason about it yet.\n2. **Select and invoke the skill.** Based on what you just read, identify\n   the relevant skill and invoke it before forming any answer or plan.\n3. **Answer or implement.** Only after the skill is loaded, use its context\n   to reason, diagnose, or write code.\n\nNever skip or reorder these steps. Do not wait for the user to name the right\nskill keyword — infer it from the artifact you read.\n\n## Contributing\n\n### Pull Requests\n\n- All PRs must be created as **drafts**. Use `gh pr create --draft` or the GitHub UI draft option.\n- Never push branches directly to `https://github.com/NVIDIA/Megatron-LM`. You must push your branch to a personal fork (e.g. `https://github.com/<your-username>/Megatron-LM`), then open a PR from the fork's branch against `NVIDIA/Megatron-LM`.\n- Commit PR changes with both `-s` and `-S`: `-s` adds the required\n  `Signed-off-by` trailer, and `-S` signs the commit so copy-pr-bot and `/ok to\ntest` can verify the pushed commit without manually specifying the SHA.\nMegatron Core engineers at NVIDIA should sign using their NVIDIA emails so they\nare automatically added to the right user groups on the internal Slack\nworkspace.\n- Read @docs/developer/contribute.md for the full contribution policy, including code style, commit message conventions, and issue guidelines.\n\n### Code Quality\n\n- After editing imports in any Python files, always run `uv run isort` on those files to fix import order before committing.\n\n### Megatron Core Process Groups\n\n- In `megatron/core` production code, avoid adding new direct reads of global\n  process groups from `parallel_state` (for example,\n  `parallel_state.get_tensor_model_parallel_group()` or directly imported\n  `get_*_group()` helpers). Prefer accepting a `ProcessGroupCollection` or an\n  explicit `torch.distributed.ProcessGroup` from the caller and passing that\n  through.\n- Allowed compatibility points include `megatron/core/parallel_state.py`,\n  `megatron/core/process_groups_config.py`, initialization/bootstrap code that\n  materializes a `ProcessGroupCollection` from MPU globals, tests, docs, and\n  migration fallbacks with an explicit comment.\n- This guidance targets Megatron Core library code. Do not apply it to\n  `megatron/training` or other training-loop code unless the PR explicitly\n  opts into that migration.\n- In reviews, flag new direct `parallel_state.get_*_group()` usage in\n  `megatron/core` unless it is one of the compatibility points above. This is\n  advisory guidance, not a CI gate.\n","category":"root","tokens":752},{"name":".cursorrules","path":".cursorrules","title":".cursorrules","content":"See CLAUDE.md for all repository guidelines.\n","category":"root","tokens":12}]}