agentleFS
NVIDIA-NeMoNVIDIA-NeMo/Megatron-Bridge/AGENTS.md

Megatron-Bridge

AGENTS.md976 starsChanged 22 days agoApache-2.0View on GitHub

Project: PyTorch-native bridge between Hugging Face and Megatron-Core. Bidirectional checkpoint conversion, pretraining, SFT, and LoRA recipes with optimized NVIDIA GPU performance. Package: megatron.bridge (Python 3.12). The skills/ directory contains structured guides for common tasks (adding models, running experiments, debugging multi-node jobs, performance tuning, etc.). Always read the relevant SKILL.md before starting any task it covers — skills are mandatory context, not optional background reading. Workflow — mandatory order for every task: 1. Pull information first. Read the commit, PR, error…

  • Reads credentials

We split this AGENTS.md into the rules it gives an agent

18 rules. About 0 are common, 7 are distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Pull information first: Read the commit, PR, error log, file, or whatever artifact the task is about.

    line 15
  2. Distinctive:

    Answer or implement: Only after the skill is loaded, use its context to reason, diagnose, or write code.

    line 19
  3. Distinctive:

    Never skip or reorder these steps.

    line 22
  4. Distinctive:

    Run the full test suite — run only the specific tests relevant to your change

    line 29
  5. Distinctive:

    Add required (non-optional) dependencies — use optional extras.

    line 30
  6. Very specific:

    Commit secrets, tokens, .env files, or environment-specific paths / account names (e.g.

    line 31
  7. Very specific:

    Use bare print() — use logging.getLogger(__name__) or print_rank_0()

    line 32
  8. Very specific:

    Before adding any new dependency to pyproject.toml

    line 35
  9. Very specific:

    Before modifying CI workflows (.github/workflows/)

    line 36
  10. Very specific:

    Before changing public API signatures in models/conversion/

    line 37
  11. Very specific:

    Run uv run pre-commit run --all-files before committing

    line 40
  12. Very specific:

    Add NVIDIA copyright headers to new Python files (except under tests/)

    line 41
  13. Very specific:

    Use uv run python -m pytest and uv run python -m torch.distributed.run, not bare pytest / torchrun

    line 43
  14. Distinctive:

    Use the current year (2026) in generated content — do not default to 2025 or any past year

    line 44
  15. Very specific:

    Use * separator for functions with multiple same-type parameters

    line 67
  16. Distinctive:

    No arbitrary defaults for config values — be explicit

    line 68
  17. Very specific:

    Commit and PR title format (Conventional Commits: <type>(<scope>): <description>)

    line 78
  18. Very specific:

    Use scripts/switch_mcore.sh to switch versions.

    line 107

≈ “Common” is an estimate: at least 1 in 5 of the 36,368 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

AGENTS.md — Megatron Bridge

Project: PyTorch-native bridge between Hugging Face and Megatron-Core. Bidirectional checkpoint conversion, pretraining, SFT, and LoRA recipes with optimized NVIDIA GPU performance. Package: megatron.bridge (Python 3.12).

Skills

The skills/ directory contains structured guides for common tasks (adding models, running experiments, debugging multi-node jobs, performance tuning, etc.). Always read the relevant SKILL.md before starting any task it covers — skills are mandatory context, not optional background reading.

Workflow — mandatory order for every task:

  1. Pull information first. Read the commit, PR, error log, file, or whatever artifact the task is about. Do not reason about it yet.
  2. Select and invoke the skill. Based on what you just read, identify the relevant skill and invoke it before forming any answer or plan.
  3. Answer or implement. Only after the skill is loaded, use its context to reason, diagnose, or write code.

Never skip or reorder these steps. Do not wait for the user to name the right skill keyword — infer it from the artifact you read.

Boundaries

NEVER:

  • Modify files inside 3rdparty/Megatron-LM/ — changes go through the upstream repo
  • Run the full test suite — run only the specific tests relevant to your change
  • Add required (non-optional) dependencies — use optional extras; submit dependency changes as a separate PR
  • Commit secrets, tokens, .env files, or environment-specific paths / account names (e.g. /home/yuya/…, usernames, cluster hostnames)
  • Use bare print() — use logging.getLogger(__name__) or print_rank_0()

ASK FIRST:

  • Before adding any new dependency to pyproject.toml
  • Before modifying CI workflows (.github/workflows/)
  • Before changing public API signatures in models/conversion/

ALWAYS:

  • Run uv run pre-commit run --all-files before committing
  • Add NVIDIA copyright headers to new Python files (except under tests/)
  • Sign off commits: git commit -s -m "message"
  • Use uv run python -m pytest and uv run python -m torch.distributed.run, not bare pytest / torchrun
  • Use the current year (2026) in generated content — do not default to 2025 or any past year

Toolchain

ActionCommandConfig
Install depsuv syncpyproject.toml, uv.lock
Install dev toolsuv sync --group dev
Lint + formatuv run pre-commit run --all-filesruff.toml, .pre-commit-config.yaml
Unit testsuv run python -m pytest tests/unit_tests/pyproject.toml [tool.pytest]
Distributed runuv run python -m torch.distributed.run --nproc_per_node=2 script.py
Type checkuv run mypy --strict path/to/file.py
Regen lock fileuv lock
Init submodulegit submodule update --init.gitmodules

Code Style

Lint and format are enforced by pre-commit hooks (ruff). See @ruff.toml for the authoritative rules. For judgment calls not covered by tooling, see @skills/linting-and-formatting/SKILL.md. Key points the linter cannot catch:

  • Type hints required on all public API functions (X | None, not Optional[X])
  • Google-style docstrings on public classes and functions
  • Use * separator for functions with multiple same-type parameters
  • No arbitrary defaults for config values — be explicit

Testing

  • No foreign setattr on config dataclasses in tests. When a test applies overrides to a recipe config via setattr(config_obj, key, value), always guard with if not hasattr(config_obj, key): raise ValueError(...) first. Setting an attribute that does not exist on the dataclass silently creates a phantom field — the test passes but the recipe would fail for a real user who never sets that key. This applies to all override patterns (model_overrides, checkpoint_overrides, config_overrides, etc.) in tests/functional_tests/.

Contributing

See @CONTRIBUTING.md for the full contributor guide, including:

  • Commit and PR title format (Conventional Commits: <type>(<scope>): <description>)
  • PR labeling taxonomy (type, area, state, risk labels)
  • Testing conventions (unit preferred, functional max 2 GPUs, L0/L1/L2 tiers)
  • Dependency management policy
  • DCO sign-off requirements
  • CI triggering (/ok to test <commit-SHA>)

Architecture

Bridge Pattern

Each supported model family lives under src/megatron/bridge/models/<family>/ with:

FileRole
bridge.pyHF ↔ Megatron conversion logic
config_mapping.pyMaps HF config → Megatron config
param_mapping.pyMaps parameter names between formats
hf_pretrained/HF model definition provider

Recipes live in src/megatron/bridge/recipes/<family>/.

AutoBridge (models/conversion/auto_bridge.py) auto-selects the correct bridge from a HF model name or path.

Megatron-Core Submodule

3rdparty/Megatron-LM/ is a git submodule pinned to a specific commit, installed as an editable package via [tool.uv.sources] in pyproject.toml. Use scripts/switch_mcore.sh to switch versions.

Tool Compatibility

This file is the single source of agent instructions. For Claude Code compatibility, create a symlink: ln -s AGENTS.md CLAUDE.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.