nemo-rl-auto-research

Autonomous NeMo-RL research agent workflow for directed hypothesis testing and open-ended discovery. Guides agents through the full experiment lifecycle: understanding recipes and environments, wiring RL or NeMo-gym runs, launching reproducible baselines and iterations, analyzing results, preserving human oversight, and using git plus TSV logs as the research ledger. Do NOT use for: bug fixes, code review, documentation, refactoring, dependency updates, or single-file changes.

2,741stars319forksUpdated 7/31/2026

Data Science & ML Git & Version Control Productivity & Workflow #reinforcement-learning #machine-learning #nvidia #experiment-tracking #git #automation

Security Assessment

Low Risk(88/100)

Detected risks:

Autonomous Shell and Training Execution(The skill autonomously executes shell commands and launches reinforcement-learning training jobs that can consume substantial GPU compute resources., It creates git branches and writes files to disk as part of its automated experiment loop, though it requires explicit user approval before branching or launching jobs and forbids destructive git operations without permission.)

Security Score88/100

About nemo-rl-auto-research

nemo-rl-auto-research is an autonomous research-agent workflow for running iterative reinforcement-learning experiments inside a NeMo-RL (or NeMo-gym) repository. It solves the problem of turning a stated objective — accuracy, reward, throughput, latency, or stability — into a disciplined, reproducible experiment campaign, using git as the durable research ledger so every hypothesis, result, and failure is preserved and auditable rather than lost in ad-hoc runs.

The skill guides the agent through the full experiment lifecycle: inspecting git state and isolating unrelated user work, choosing a shared branch prefix, reading the target recipe and relevant code paths (examples/run_grpo.py, nemo_rl/models, algorithms, environments), translating user stop rules into monitorable values (experiment count, deadline, timeout, target metric), running a baseline first, then looping one hypothesis per branch with a single focused commit and a run. Results are recorded in an untracked TSV ledger with per-experiment log directories. It chooses execution environments deliberately (local GPU, Slurm, or Kubernetes via launch-nemo-rl) and integrates companion skills for session memory and Brev-instance etiquette. It explicitly forbids silent destructive git operations and requires user approval before launching compute-intensive jobs.

It targets ML researchers and engineers running long-running NeMo-RL/NeMo-gym research campaigns who want autonomous discovery or directed hypothesis testing with strong reproducibility and human oversight. It is explicitly not for bug fixes, code review, documentation, refactoring, dependency updates, or single-file changes.

FAQ

What does this skill actually run?

It creates git branches, writes files, and executes shell commands including RL training jobs that may consume significant GPU resources, logging each run into an untracked TSV ledger and per-experiment log directory.

What are the prerequisites?

A NeMo-RL or NeMo-gym repository with dependencies treated as ready, access to the recipe's data/checkpoints/launcher, and suitable compute (local GPUs, Slurm, or a Kubernetes/nrl-k8s launcher). Brev instances are auto-detected and handled via a companion etiquette skill.

How does it keep experiments organized?

Every experiment lives on its own branch under one shared prefix (e.g. autoresearch/DATE-recipe), with a baseline branch first, one hypothesis-focused commit per branch, and keep/discard/crash status recorded in a TSV ledger kept outside committed history.

Does it perform destructive git or compute operations automatically?

No. It requires explicit user approval before creating branches or launching jobs, never runs destructive git operations like reset or force-push without permission, and leaves unrelated dirty files untouched.

When should I not use this skill?

For bug fixes, code review, documentation, refactoring, dependency updates, or single-file changes — it is scoped to multi-experiment research campaigns only.