agentleFS
NVIDIA-NeMoNVIDIA-NeMo/RL/skills/linting-and-formatting/SKILL.md

linting-and-formatting

Skill2.1k starsChanged 20 days agoApache-2.0View on GitHub

Code style guidelines for NeMo-RL (Python and shell). Covers naming, indentation, comments, docstrings, reflection avoidance, and uv usage.

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 3 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use uv run to execute scripts.

    line 18
  2. Distinctive:

    Avoid shadowing variables declared in an outer scope.

    line 53
  3. Distinctive:

    Use Google style docstrings (parseable by Sphinx).

    line 64
  4. Very specific:

    When a function has multiple parameters of the same type that could easily be swapped by mistake, use a bare * to force keyword-only …

    line 68
  5. Distinctive:

    Do not use reflection when functionality can be achieved without it.

    line 90
  6. Very specific:

    When you add a new module under a type-checked area, add it to pyrefly.toml project-includes.

    line 112
  7. Very specific:

    Put imports at module top.

    line 118

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill 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
SKILL.md

Code Style

Style Guides

This repository is Python-first.

uv

Use uv run to execute scripts. Do not activate a virtual environment and call python directly.

Do:

uv run examples/run_grpo.py

Don't:

source .venv/bin/activate
python examples/run_grpo.py

Exception: Dockerfile.ngc_pytorch is exempt from this rule.

Python Standard

Code must conform to Python 3.13.13+.

Indentation

Indent with 4 spaces. Do not use tabs.

Naming

KindConventionExample
Filessnake_casesome_file.py
ClassesPascalCaseclass SomeClass
Functions/methodssnake_casedef my_awesome_function():
Local variablessnake_casemy_variable = ...
Variables starting with a numberprefix kk_99th_percentile = ...
Global variablesupper snake_case + prefix GG_MY_GLOBAL = ...
Constantsupper snake_caseMY_CONSTANT = ...
  • Avoid shadowing variables declared in an outer scope.
  • Initialize all externally visible members of a class in the constructor.

Comments

  • For interfaces used outside a file, prefer docstrings over comments.
  • Comments are for code within a function or file-local interfaces.
  • Commented-out code must have a comment explaining why it is commented out. Otherwise remove it before merging.

Docstrings

Use Google style docstrings (parseable by Sphinx).

Enforce Keyword Arguments for Ambiguous Parameters

When a function has multiple parameters of the same type that could easily be swapped by mistake, use a bare * to force keyword-only arguments starting from where the ambiguity begins. This prevents callers from accidentally transposing arguments.

Don't:

def loss_fn(input: Tensor, cp_group: ProcessGroup, tp_group: ProcessGroup, cp_rank: int, tp_rank: int):
    ...

# Caller can silently swap cp_group/tp_group or cp_rank/tp_rank
loss_fn(x, tp_group, cp_group, tp_rank, cp_rank)  # wrong order, no error

Do:

def loss_fn(input: Tensor, *, cp_group: ProcessGroup, tp_group: ProcessGroup, cp_rank: int, tp_rank: int):
    ...

# Caller must name every argument — swaps are impossible
loss_fn(x, cp_group=cp_group, tp_group=tp_group, cp_rank=cp_rank, tp_rank=tp_rank)

Avoid Reflection

Do not use reflection when functionality can be achieved without it.

Don't:

def make_complex(*args):
    x, y = args
    return dict(**locals())

Do:

def make_complex(x, y):
    return {'x': x, 'y': y}

Type Annotations

Annotate new functions and methods — both parameters and return type. When you add a parameter to an existing signature, type it, and match the type already used at the call site (don't leave a new arg untyped while the caller already declares it, e.g. def __init__(self, teacher_worker_groups=None) when the caller passes teacher_worker_groups: Optional[dict[str, Any]]).

When you add a new module under a type-checked area, add it to pyrefly.toml project-includes. pyrefly checks an explicit allow-list of files, so a new file that isn't listed silently escapes type-checking and its annotations are never verified.

Imports

Put imports at module top. Defer an import into a function body ONLY to break a circular import or to avoid loading a heavy/optional dependency in a path that shouldn't need it — and when you do, add a one-line comment saying which. An in-function import with no such reason should move to the top. In particular, deferring stdlib (concurrent.futures, collections, …) or a module that is already imported at module top buys nothing — hoist it.

Download now (ZIP)

Trending

Steady: 0 new projects took it in the last 4 weeks, none the 4 weeks before.thin data

Week of Aug 30: 0 new projectsWeek of Sep 6: 0 new projectsWeek of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 0 new projectsWeek of Oct 11: 0 new projectsWeek of Oct 18: 0 new projects
Aug 2026Sep 2026Oct 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 0 in all, so this is a hint, not a trend.

Who's talking about NVIDIA-NeMo/RL

The biggest 5 of 52 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 52

Talked about on GitHub and Bluesky (52 times).

On GitHub · 50

45 more on GitHub

Does it work?

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

Reviews can't be read right now.

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.