# Compute Env Setup

Set up a compute environment on a remote provider so Claude Science jobs can run there.

- Repository: https://github.com/HughYau/AcademicForge (2620 stars)
- Category: AI and agents
- License: Apache-2.0
- Last updated: 2026-08-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add HughYau/AcademicForge --skill compute-env-setup -g -a claude-code -y`
Codex: `npx skills add HughYau/AcademicForge --skill compute-env-setup -g -a codex -y`
Cursor: `npx skills add HughYau/AcademicForge --skill compute-env-setup -g -a cursor -y`
Gemini CLI: `npx skills add HughYau/AcademicForge --skill compute-env-setup -g -a gemini-cli -y`

## Description

Set up a compute environment on a remote provider so Claude Science jobs can run there. Covers direct SSH/conda hosts, Slurm clusters, container-via-bridge runners, and managed-API providers (Modal, GCP, RunPod). Use when standing up a new provider, porting an env to a different backend, adding a tool that needs its own software stack, or wiring weight caches. Triggers on "new compute provider", "set up env on", "port env to", "build GPU image", "weight cache", "compute_details", "conda env on the box", "apptainer on slurm".

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Setting up compute environments on a remote provider

## Overview

What's invariant across every backend is what a job *needs*: a software stack (specific package versions, often with load-bearing install ordering), possibly some large model weights placed where the tool will find them, and a resource shape. What varies, a lot, is how a given provider materialises those three things and how an env name gets resolved to them at submit time. This skill is about keeping one declarative spec that says *what* the environment is, and treating *how it gets built and addressed on this provider* as something you figure out once per provider. The work ranges from minutes (another conda env on a host that has ten) to days (GPU image + weight cache + egress on a fresh backend), and most of the long tail is diagnosing why the documented invocation doesn't work even though every import succeeds.

**Before building anything:** `compute_details({provider, mode:"read"})`. The env, or a near-match you can extend, may already exist. The doc you get back is also where you'll record what you set up.

## Provider shapes

These are not exhaustive and they blend at the edges (a Slurm node can run Apptainer containers built from the same Dockerfile a cloud backend uses). The point is to recognise which shape you're in, because that determines what "build", "register", and "resolve" mean.

The rest: https://github.com/HughYau/AcademicForge/blob/HEAD/skills/claude-science/compute-env-setup/SKILL.md