remote-compute-ssh

You've decided to run this on the user's SSH host. This skill covers the orchestration layer — partitions, env activation, job scripts, file transfer, recovery — not the science; what to run and why comes from the task and its own skills. Each c.submit_job() puts an approval modal in front of the user and, once approved, spends their allocation; a string of failed submits costs their attention, their compute, and their trust. So the shape of a good run is: read what's already known about this host, ask once for what isn't, land the first submit, and write down what you learned about the host or compute provider so the next session goes straight to the job.

Workflow

Every host.compute.* call in this skill runs via the repl tool (the control-plane kernel), not the python tool. Job submission opens the user's approval modal and the SSH connection from the orchestrator's own process; that has to happen outside the sandboxed data workspace, so host.compute simply isn't attached in the python tool (you'd see host has no method 'compute'). The two kernels share your workspace directory but not memory, so the rhythm is: prepare inputs in a python cell (write ./in.dat, pickle what the job needs), run create → submit_job in a repl cell and let the cell return — the kernel never blocks on compute. Then call the wait_for_notification brain-tool to park until the daemon's poller emits the compute_done notification, and return to the python tool to read the harvested hpc/<jobId>/ files. The repl tool is stdlib-only (python -I -S) — keep pandas/numpy work in the python tool and pass data through files.

Start with the compute_details({provider, mode:'read'}) tool, then bind once: c = host.compute.create(provider). The doc's shape tells you how much discovery is left: ### env: blocks and gotchas mean prior sessions did the legwork — trust it. A bare ## Resources header means first contact — spend one batched c.call_command('id; module avail 2>&1 | head -40; ls -la ~', intent=..., login_shell=True) and one ask_about_compute now, before any submit. The header's scheduler: line is detection, not ground truth; none on a thin login node means a heavy direct-exec job would crowd other users, so when the resources look thin and the details doc has no prior note, ask first.

If the prose doc has a known-working activation, write it directly into your command (e.g. source <path>/activate && <tool> ...). If it doesn't, find one via c.call_command() (module avail X, conda env list, likely app dirs) or ask. Install only once you've established the tool genuinely isn't there — user-space (venv/conda under scratch), via c.call_command() for a quick install or as its own c.submit_job() if it needs a build node. Whichever route produced an activation, run the entrypoint once via c.call_command() before building the real job on it.

Then job = c.submit_job(...) (see below). inputs=[{src:'file', dst_filename: ...}] stages the file for you — there's no c.upload() step, and once submitted there's nothing to verify with c.call_command('cat ...'); the job reads ./<dst_filename> from its own workdir. End the cell — submit_job returns immediately and the daemon's background poller polls the remote, harvests everything the job wrote into your workspace under hpc/<jobId>/, and emits a compute_done notification when done.

Park on the wait_for_notification brain-tool until that notification arrives. Its payload carries {job_id, status, exit_code, featured_files, output_file_count, ...} — featured_files is the subset matching your featured outputs: globs (omitting outputs: features everything). Publish what you want with save_artifacts(payload['featured_files']) — that step is what gives them provenance and surfaces them in the artifact panel. If you need the full result dict (all output_files, left_on_remote, etc.), re-enter a repl cell and call r = c.attach_job(job_id).result() — a non-blocking read of what the poller already harvested. open(r['output_files'][i]) reads any harvested file directly. Chain a remote-resident output via inputs:[{remote_path: r['left_on_remote'][i]['uri']}]. Between the notification and close() you can still c.download(f"{job.workdir}/<file>") for anything the harvest missed. c.download('/any/absolute/host/path') works for any readable file on the host, not just job outputs — paths outside scratch/data_roots raise an approval card the user clicks Allow on. When the user asks you to fetch a host file, call c.download() with the path they gave; the approval card is the authorization gate, so don't refuse on their behalf and don't cp into scratch first to dodge it. Dotfiles / paths under a dot-directory (~/.ssh/*, .gitconfig, .env, …) get a hardened per-file confirmation. c.close() once you've confirmed — it cleans up the job workdirs on the host. Hand back the result verbatim.