runpod-job

Runpod Job Skill

Use this skill for bounded Runpod work.

Default path: the human manually creates a Runpod Pod with the desired GPU, gives the agent the pod_id, and the agent works against that Pod through a saved opencolab gpu ssh profile plus transcript-backed gpu ssh session commands. This is a capacity-driven default: the OpenColab-managed Runpod CLI path still works, but live GPU stock is often unavailable when the agent tries to provision on demand, and the gpu ssh session flow avoids leaving the agent parked inside a raw interactive ssh shell.

Do not use raw Runpod APIs unless the user is explicitly fixing OpenColab itself.

Preferred execution paths:

• default: saved opencolab gpu ssh profile plus opencolab gpu ssh session start|read|write|stop for a user-managed Pod identified by pod_id
• bounded helpers: opencolab gpu ssh profile test, plus narrow scp, rsync, or one-shot ssh only when file transfer or an explicit user request requires them
• optional: opencolab gpu server ... and opencolab gpu job ... only when the user explicitly wants OpenColab-managed provisioning, detached run_id tracking, or the managed CLI lifecycle

Core Rules

• Default to the manual user-managed Pod workflow through opencolab gpu ssh.
• If the user has not yet created a Pod, ask them to create one manually with the desired GPU type and then send the pod_id.
• Do not start by checking Runpod capacity or creating OpenColab server targets unless the user explicitly wants the OpenColab-managed path.
• Treat a user-supplied pod_id as a manual path outside the normal OpenColab run_id lifecycle.
• Do not invent a run_id for a manual Pod.
• Do not claim that opencolab gpu job exec works against a raw pod_id; it does not.
• Save or update a project-scoped manual SSH profile with opencolab gpu ssh profile save ... once the user provides enough details, and prefer --set-default true when the active agent is likely to reuse that Pod.
• Prefer opencolab gpu ssh profile test ... before starting a session so host and port can be refreshed from Runpod Pod metadata when local Runpod auth is available and SSH reachability is validated before real work starts.
• Ask for the SSH connection details needed to save the profile if they are not already available locally.
• Use opencolab gpu ssh session start|read|write|stop as the default command and inspection path for manual Pods rather than opening a raw interactive ssh shell.
• Keep commands bounded and task-focused. This skill is for concrete remote work, not open-ended interactive shells.
• Do not leave a manual SSH session sitting at a shell prompt or endless stream unless the user explicitly wants that. Stop it explicitly when you have the output you need.
• Prefer minimal rsync, scp, or one small uploaded script over broad workspace copies when files need to move. Those are bounded helpers, not the default control path.
• Never blindly forward all environment variables or secrets.
• If a manual Pod task fails, explain the failure clearly, call out any missing tracking or session limitations, and propose the next useful step.
• If OPENCOLAB_PROGRESS_FILE is available and the task is long enough to justify updates, emit bounded progress events for waiting on the user-managed Pod, saving the manual SSH profile, validating the profile, starting the manual SSH session, syncing files, sending the remote command, reading transcript output, copying outputs back, stopping the session, and blocked states.
• Only use the OpenColab-managed CLI path when the user explicitly asks for it or explicitly wants a run_id and OpenColab-managed status/log/artifact tracking.
• On the optional managed path, launch with opencolab gpu job start --wait false, return the run_id promptly, refresh the run with opencolab gpu job status --run-id <run_id> before reading logs, and review bootstrap, stdout, stderr, and poller when summarizing the run.