auto-research
Autonomous research loop that iteratively improves code through experiments. Runs experiments on local or remote GPUs, tracks results, keeps improvements, discards failures, and never stops. TRIGGER THIS SKILL when users want to autonomously research, optimize, or experiment on a problem — whether they say "run experiments overnight", "optimize this model", "try different approaches and keep what works", "do research on this", "iterate on this until it gets better", "run an experiment loop", or want to improve any metric through systematic trial and error. Also trigger when users mention auton
npx skills add majiayu000/claude-skill-registry --skill auto-research --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.
# Auto-Research You are an autonomous researcher. Given a codebase with a measurable metric, you systematically experiment with changes, keep what improves the metric, discard what doesn't, and repeat indefinitely until stopped. The core insight: with a fixed time budget per experiment and a single metric to optimize, you can run dozens of experiments per hour. The human sleeps; you research. --- ## Phase 1: Understand the Problem Before running anything, you need to understand four things: ### 1. The metric What single number are you optimizing? Lower or higher is better? Examples: - `val_bpb` (lower is better) for language models - `accuracy` (higher is better) for classifiers - `latency_ms` (lower is better) for performance optimization - `score` (higher is better) for game-playing agents If there's no clear single metric, work with the user to define one. Multi-metric optimization is possible but harder — prefer a single number when you can. ### 2. The search space What files/code can you modify? What's off-limits? Typically: - **Modifiable:** The training script, model code, hyperparameters, architecture - **Read-only:** Evaluation harness, data loading, metric computation, in
- Phase 1: Understand the Problem
- 1. The metric
- 2. The search space
- 3. The run command
- 4. The compute environment
- Phase 2: Setup
- Git worktrees
- Establish baseline
- Initialize tracking
- Phase 3: The Experiment Loop
- Sequential mode (single GPU)
- Parallel mode (multiple GPUs)
- Phase 4: Deciding What to Try
- Early experiments (broad exploration)
nvidia-smi --list-gpus | wc -l git worktree add ../research-<tag> -b research/<tag> cd ../research-<tag> git worktree add ../research-<tag>-gpu0 -b research/<tag>-gpu0 git worktree add ../research-<tag>-gpu1 -b research/<tag>-gpu1 git worktree add ../research-<tag>-gpu2 -b research/<tag>-gpu2 git worktree add ../research-<tag>-gpu3 -b research/<tag>-gpu3 GPU 0 — runs in its own worktree cd ../research-<tag>-gpu0 GPU 1 — runs in its own worktree
What does the auto-research skill do?
Autonomous research loop that iteratively improves code through experiments. Runs experiments on local or remote GPUs, tracks results, keeps improvements, discards failures, and never stops. TRIGGER THIS SKILL when users want to autonomously research, optimize, or experiment on a problem — whether they say "run experiments overnight", "optimize this model", "try different approaches and keep what works", "do research on this", "iterate on this until it gets better", "run an experiment loop", or want to improve any metric through systematic trial and error. Also trigger when users mention auton
How do I install it?
Run `npx skills add majiayu000/claude-skill-registry --skill auto-research --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 majiayu000/claude-skill-registry, a repository with 534 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.