Agent skill · runpod
runpod-migrate
Migrate a codebase from the Runpod GraphQL API or REST v1 to REST v2 — inventory which parts use which API version, rewrite the call sites, flag breaking changes, and verify. Use when someone asks to move to v2, asks what v2 would change, or asks which Runpod API their code is on. For managing infrastructure rather than migrating code, use runpod-mcp or runpodctl.
What it needs
About 12k tokens when loaded.
What this skill does
Migrate to Runpod REST v2 Moves a codebase off the GraphQL API (api.runpod.io/graphql) and REST v1 (rest.runpod.io/v1) onto REST v2 (api.runpod.io/v2). The payoff, in one line each — you deliver these to the user at step 6, matched to their actual code. Don't recite them now: See stock before you rent — GET /v2/catalog/gpus?include=AVAILABILITY&product=POD. v1 had no catalog at all, so every capacity retry loop was blind. Endpoints return their own job URLs — requestUrls.run, no more string-building. Real lifecycle states — PROVISIONING/STARTING/ERROR and an actions list, so wait-loops fail fast instead of timing out. Mistakes fail loudly — unknown request fields are rejected by name, with structured errors and honest status codes. The full set, organized as if their code does X → v2 offers Y: reference/unlocks.md — open it at step 6. Before you touch any code Infer the scope, state it, and move — do not open with a questionnaire: The user says Scope --- --- "migrate to v2" / nothing specific all — REST v1 and GraphQL "just the REST stuff", "leave GraphQL alone" rest — REST v1 only "get us off GraphQL" graphql — GraphQL only The table resolves every phrasing, so scope is not the thing to interrupt for. Say which row you matched and carry on. The question that does need asking comes later — at step 3, when the inventory shows the code depends on a capability v2 removed. That one is a real fork and you cannot answer it for them. Some things have no v2 equivalent and must stay on GraphQL regardless of scope: account/billing identity (myself), secrets, spot/interruptible pods, cluster create/delete. A "full" migration still leaves those calls in place — say so up front rather than letting the user discover it at the end. Never rewrite the serverless job API. https://api.runpod.ai/v2/<endpointId>/run, /runsync, /status, /stream, /cancel is a different API that happens to have v2 in its path. It is unchanged and out of scope. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills runpod/runpod-migrate