corl-reproducibility
Use when making a CoRL robot-learning paper reproducible — pinning simulator and driver versions, releasing training configs, demonstration data and checkpoints, documenting hardware setups that cannot be rerun, seed policy, evaluation scripts, and honest availability statements for code, data, and robot platforms.
Profile →npx skills add brycewang-stanford/Awesome-Journal-Skills --skill corl-reproducibility --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# CoRL Reproducibility Robot-learning papers have a split reproducibility problem: the *training* half is software and can in principle be rerun anywhere, while the *hardware* half is a physical setup nobody else owns. Strong CoRL papers treat these halves differently — the software half is made **rerunnable**, the hardware half is made **auditable** — and say plainly which is which. ## The rerunnable half: simulation and training The silent reproducibility killers in this field are version-shaped: - **Simulator versions change physics.** Contact solvers, default damping, and collision margins shift between releases of MuJoCo, Isaac, PyBullet, and friends; a policy's success rate is a function of the simulator build. Pin the exact version and any physics-relevant flags. - **Environment wrappers drift.** Task-suite repositories (benchmark forks, custom reward shims) move under you; record the commit hash of every env repo, not just your own. - **GPU nondeterminism.** cuDNN autotuning and atomics make bit-identical training runs unrealistic — so define reproducibility at the *distribution* level: same configs + fresh seeds should land inside your reported seed spread. ```yaml # repro
- The rerunnable half: simulation and training
- The auditable half: hardware
- Data and checkpoint release
- During review vs after acceptance
- Availability statement patterns
- Pre-submission audit
What does the corl-reproducibility skill do?
Use when making a CoRL robot-learning paper reproducible — pinning simulator and driver versions, releasing training configs, demonstration data and checkpoints, documenting hardware setups that cannot be rerun, seed policy, evaluation scripts, and honest availability statements for code, data, and robot platforms.
How do I install it?
Run `npx skills add brycewang-stanford/Awesome-Journal-Skills --skill corl-reproducibility --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From brycewang-stanford/Awesome-Journal-Skills, a repository with 909 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.