菜单
Reproduce a working project environment from one lab server on another — code at the same commit, a CUDA-compatible python env, and a smoke test. Use for "make this run on host B too" or setting up a new server.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Find what's eating disk on full lab servers — old checkpoints, wandb and cache junk — and produce a deletion plan. Report-only; deletion needs per-path human approval. Use when a disk is full or the user asks to free space.
Compare experiment results across servers — differing hyperparameters and final metrics from local wandb data, with dashboard links. Use for "which ablation won" or comparing runs of a project.
Morning briefing across all lab servers — what finished or crashed overnight, which GPUs are free, which disks are filling up. Use when the user asks for a briefing, "what happened overnight", or overall lab/server status.
Launch a training run on the best lab server — picks a host by data locality and free GPUs, verifies code and environment, starts it in a detached tmux session. Use when the user wants to run, launch, or train something on the servers.
Check on the user's running experiments across all servers — progress, loss, ETA, stalled or crashed. Use for "how are my runs", "is training still going", or checking a specific experiment.
Launch a hyperparameter sweep distributed across free GPUs on multiple lab servers, one detached tmux session per config. Use when the user wants to run several variants of an experiment at once.
| name | repro-env |
| description | Reproduce a working project environment from one lab server on another — code at the same commit, a CUDA-compatible python env, and a smoke test. Use for "make this run on host B too" or setting up a new server. |
Input: a project (directory on the source host) and a target host.
Fingerprint the source via run_command on host A:
git -C <dir> remote -v; git -C <dir> rev-parse HEAD; git -C <dir> status --porcelain | headwhich python; python -V; pip freeze | head -60
(or conda env export --no-builds | head -60 for conda projects)python -c 'import torch; print(torch.__version__, torch.version.cuda)'Check the target's ceiling. Driver and CUDA on B come from
list_hosts. If B's driver can't run A's CUDA build, pick the closest
torch build that works on B — and say so explicitly.
Code onto B: clone from the git remote and check out the same commit.
No usable remote? → copy_path the directory (excluding wandb/, runs/,
old checkpoints) after the user approves the size.
Env on B — the slow part goes in a detached tmux via start_session
(background) so nothing times out: create the venv/conda env with matching
python; install torch matching B's CUDA; pip install -r requirements.txt
if present, else the frozen list from step 1.
Smoke test:
python -c 'import torch; print(torch.cuda.is_available())'
then import the project's main package or run its smallest entrypoint with
--help.
What matches (commit, python, torch), what differs and why (driver limits, unavailable pins), and the exact activation command to use on B. Never modify anything on the SOURCE host.