Deploy and run ML experiments on local or remote GPU servers. Use when user says \"run experiment\", \"deploy to server\", \"\u8dd1\u5b9e\u9a8c\", or needs to launch training jobs.
npx skills add https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep --skill run-experiment
Deploy and run ML experiment: $ARGUMENTS
Read the project's AGENTS.md to determine the experiment environment:
gpu: vast, vast_instance, SSH host/port, remote path, and optional auto_destroygpu: modal, app/function name, image/dependency setup, and secretsIf no server info is found in AGENTS.md, ask the user.
Environment contract (../shared-references/compute-env-contract.md): before
building or trusting any environment, read the provider's env ledger
(.aris/compute/<provider>.md) — an unchanged spec hash means warm-reuse, a
changed one means rebuild. New env → write the declarative spec first, render it
for this provider's shape, and never declare it ready on import-success alone:
run the seeded kernel witness, and after any rebuild/doc edit run the
agent-follows-doc pass (a fresh subagent executes the documented invocation
verbatim and reports doc-vs-reality divergence).
Check GPU availability on the target machine:
Remote:
ssh <server> nvidia-smi --query-gpu=index,memory.used,memory.total --format=csv,noheader
Local:
nvidia-smi --query-gpu=index,memory.used,memory.total --format=csv,noheader
# or for Mac MPS:
python -c "import torch; print('MPS available:', torch.backends.mps.is_available())"
Free GPU = memory.used < 500 MiB.
Check the project's AGENTS.md for a code_sync setting. If not specified, default to rsync.
Only sync necessary files — NOT data, checkpoints, or large files:
rsync -avz --include='*.py' --exclude='*' <local_src>/ <server>:<remote_dst>/
code_sync: git is set in AGENTS.md)Push local changes to remote repo, then pull on the server:
# 1. Push from local
git add -A && git commit -m "sync: experiment deployment" && git push
# 2. Pull on server
ssh <server> "cd <remote_dst> && git pull"
Benefits: version-tracked, multi-server sync with one push, no rsync include/exclude rules needed.
If gpu: vast is configured, treat the Vast.ai machine as a remote server with an explicit lifecycle:
Do not silently ignore a requested Vast.ai route. If Vast.ai CLI credentials or instance metadata are missing, stop and ask the user to configure them.
wandb: true in AGENTS.md)Skip this step entirely if wandb is not set or is false in AGENTS.md.
Before deploying, ensure the experiment scripts have W&B logging:
import wandb or wandb.init. If present, skip to Step 4. import wandb
wandb.init(project=WANDB_PROJECT, name=EXP_NAME, config={...hyperparams...})
# Inside training loop:
wandb.log({"train/loss": loss, "train/lr": lr, "step": step})
# After eval:
wandb.log({"eval/loss": eval_loss, "eval/ppl": ppl, "eval/accuracy": acc})
# At end:
wandb.finish()
train/loss — training loss per steptrain/lr — learning rateeval/loss, eval/ppl, eval/accuracy — eval metrics per epochgpu/memory_used — GPU memory (via torch.cuda.max_memory_allocated())speed/samples_per_sec — throughput ssh <server> "wandb status" # should show logged in
# If not logged in:
ssh <server> "wandb login <WANDB_API_KEY>"
> The W&B project name and API key come from AGENTS.md (see example below). The experiment name is auto-generated from the script name + timestamp.
For each experiment, create a dedicated screen session with GPU binding:
ssh <server> "screen -dmS <exp_name> bash -c '\
eval \"\$(<conda_path>/conda shell.bash hook)\" && \
conda activate <env> && \
CUDA_VISIBLE_DEVICES=<gpu_id> python <script> <args> 2>&1 | tee <log_file>'"
Use the same SSH + screen pattern, but include the Vast.ai instance id, public SSH endpoint, and remote working directory in the report. If auto_destroy: true, write a cleanup command to the run notes before launch.
Record the estimated hourly cost, expected run duration, and cleanup owner. If the command fails to start or the instance becomes unreachable, do not relaunch blindly; capture logs and ask for a rescue / second opinion before spending more GPU time.
If gpu: modal is configured, deploy through Modal instead of SSH:
modal run <module_or_app>.py -- <args>
Before launch, verify required secrets, volumes, image dependencies, and output persistence. If Modal is requested but the project lacks Modal configuration, stop and ask the user to configure it rather than falling back to local execution.
Record the Modal app/function name, GPU type, timeout, mounted volumes, and where results will be stored. If Modal reports an image, secret, or volume error, preserve the exact error and run a configuration fix before retrying.
# Linux with CUDA
CUDA_VISIBLE_DEVICES=<gpu_id> python <script> <args> 2>&1 | tee <log_file>
# Mac with MPS (PyTorch uses MPS automatically)
python <script> <args> 2>&1 | tee <log_file>
For local long-running jobs, use run_in_background: true to keep the conversation responsive.
Remote:
ssh <server> "screen -ls"
Local:
Check process is running and GPU is allocated.
After deployment is verified, check ~/.codex/feishu.json:
experiment_done notification: which experiments launched, which GPUs, estimated time"off": skip entirely (no-op)gpu: vast and auto_destroy: true)Only run this after the experiment has completed and results/logs/checkpoints have been copied or otherwise persisted.
auto_destroy: true.If any artifact copy fails, do not destroy the instance.
tee to save logs for later inspectionrun_in_background: true to keep conversation responsiveUsers should add their server info to their project's AGENTS.md:
## Remote Server
- SSH: `ssh my-gpu-server`
- GPU: 4x A100 (80GB each)
- Conda: `eval "$(/opt/conda/bin/conda shell.bash hook)" && conda activate research`
- Code dir: `/home/user/experiments/`
- code_sync: rsync # default. Or set to "git" for git push/pull workflow
- wandb: false # set to "true" to auto-add W&B logging to experiment scripts
- wandb_project: my-project # W&B project name (required if wandb: true)
- wandb_entity: my-team # W&B team/user (optional, uses default if omitted)
## Vast.ai
- gpu: vast
- vast_instance: 123456
- SSH: `ssh -p 12345 [email protected]`
- Code dir: `/workspace/experiments/`
- auto_destroy: false
## Modal
- gpu: modal
- modal_app: `train.py`
- modal_secrets: `wandb-secret`
- modal_volume: `experiment-results`
## Local Environment
- Mac MPS / Linux CUDA
- Conda env: `ml` (Python 3.10 + PyTorch)
> W&B setup: Run wandb login on your server once (or set WANDB_API_KEY env var). The skill reads project/entity from AGENTS.md and adds wandb.init() + wandb.log() to your training scripts automatically. Dashboard: https://wandb.ai/<entity>/<project>.
Assess Kubernetes workloads and cluster configuration for AKS Automatic compatibility. Identifies incompatibilities, generates fixes, and guides migration from AKS Standard to AKS Automatic. WHEN: migrate to AKS Automatic, check AKS Automatic readiness, validate manifests for Automatic, assess cluster for Automatic compatibility, fix deployment for Automatic compatibility, identify AKS Automatic migration blockers, is my cluster ready for AKS Automatic.
Discovers available Azure OpenAI model capacity across regions and projects. Analyzes quota limits, compares availability, and recommends optimal deployment locations based on capacity requirements. USE FOR: find capacity, check quota, where can I deploy, capacity discovery, best region for capacity, multi-project capacity search, quota analysis, model availability, region comparison, check TPM availability. DO NOT USE FOR: actual deployment (hand off to preset or customize after discovery), quota increase requests (direct user to Azure Portal), listing existing deployments.
Interactive guided deployment flow for Azure OpenAI models with full customization control. Step-by-step selection of model version, SKU (GlobalStandard/Standard/ProvisionedManaged), capacity, RAI policy (content filter), and advanced options (dynamic quota, priority processing, spillover). USE FOR: custom deployment, customize model deployment, choose version, select SKU, set capacity, configure content filter, RAI policy, deployment options, detailed deployment, advanced deployment, PTU deployment, provisioned throughput. DO NOT USE FOR: quick deployment to optimal region (use preset).
Unified Azure OpenAI model deployment skill with intelligent intent-based routing. Handles quick preset deployments, fully customized deployments (version/SKU/capacity/RAI policy), and capacity discovery across regions and projects. USE FOR: deploy model, deploy gpt, create deployment, model deployment, deploy openai model, set up model, provision model, find capacity, check model availability, where can I deploy, best region for model, capacity analysis. DO NOT USE FOR: listing existing deployments (use foundry_models_deployments_list MCP tool), deleting deployments, agent creation (use agent/create), project creation (use project/create).
Intelligently deploys Azure OpenAI models to optimal regions by analyzing capacity across all available regions. Automatically checks current region first and shows alternatives if needed. USE FOR: quick deployment, optimal region, best region, automatic region selection, fast setup, multi-region capacity check, high availability deployment, deploy to best location. DO NOT USE FOR: custom SKU selection (use customize), specific version selection (use customize), custom capacity configuration (use customize), PTU deployments (use customize).
This skill should be used when working with LaminDB, an open-source data framework for biology that makes data queryable, traceable, reproducible, and FAIR. Use when managing biological datasets (scRNA-seq, spatial, flow cytometry, etc.), tracking computational workflows, curating and validating data with biological ontologies, building data lakehouses, or ensuring data lineage and reproducibility in biological research. Covers data management, annotation, ontologies (genes, cell types, diseases, tissues), schema validation, integrations with workflow managers (Nextflow, Snakemake) and MLOps platforms (W&B, MLflow), and deployment strategies.
Latch platform for bioinformatics workflows. Build pipelines with Latch SDK, @workflow/@task decorators, deploy serverless workflows, LatchFile/LatchDir, Nextflow/Snakemake integration.
Run Python code in the cloud with serverless containers, GPUs, and autoscaling. Use when deploying ML models, running batch processing jobs, scheduling compute-intensive tasks, or serving APIs that require GPU acceleration or dynamic scaling.
Take wanshuiyin/auto-claude-code-research-in-sleep-run-experiment from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.