remote-compute-ops

# Remote compute operations Use this skill as the provider-neutral workflow for remote GPU and server work. The provider is an adapter, not the name of the skill: RunPod, Massed Compute, and an owned/virtual server must all follow the same evidence, transport, lifecycle, and handoff rules. When auditing this skill or designing a plan offline, do not call a provider, SSH, or bridge at all; state that live mode/identity is unproven. The read-only lookup below applies only when the user explicitly asks to inspect live remote state. ## Non-negotiable transport rule Reuse the already-created bridge or live connection before opening a new one. The purpose is reliable, rate-limit-compliant operation and avoiding unnecessary authentication attempts; never disguise traffic, evade a provider limit, rotate identities, or bypass a ban. - Inspect the local connection registry/bridge health when one exists. A registry is a coordination hint, not proof that a tunnel is alive. Resolve the existing helper through `%USERPROFILE%\\.claude\\scripts\\conn_registry.py` on Windows or `$HOME/.claude/scripts/conn_registry.py` on POSIX when that file exists; if it is not discoverable, report “registry unavailable” instead of guessing a path. - In a read-only investigation, do not create or re-register a bridge. If a live route is required, allow at most one explicitly authorized health probe. Record the host alias/route, registry entry age, session owner, local PID/service or contro...