[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PP9PRZJJHNF10N95P2C10J":3,"skill-same:01M6PP9PRZJJHNF10N95P2C10J":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":66,"ownerDescription":6,"updatedAt":67,"install":68,"resources":81},"01M6PP9PRZJJHNF10N95P2C10J","runpod-pod-doctor",null,"Diagnose a Runpod Pod that is unreachable, GPU-blind or stuck, and perform a recovery action only when the user authorizes one. Use when an existing Pod misbehaves, through the Runpod MCP tools: its proxy URL answers 502, CUDA is not available inside the container, a restarted Pod has no GPU, the user wants a Pod's logs read, an account-wide check for stuck Pods, or the stop-versus-terminate decision for a Pod they already have. Read-only until the user asks for an action.","runpod\u002Frunpod-plugins-official","runpod","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F95939477?v=4","01M6CFSV7PCCKKMKEV6AM8XC7H","Runpod","01M6CFSVC1QMHFR2P1HF14EZ08",49,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-pod-doctor\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[9,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"doctor","pod doctor","runpod pod doctor","when","availability","stop","Tools","action","read","port","log","logs","disk","URL","unreachable","MCP","only","decision","volume","2026-11-10 10:12:30",false,"---\nname: runpod-pod-doctor\ndescription: 'Diagnose a Runpod Pod that is unreachable, GPU-blind or stuck, and perform a recovery action\n  only when the user authorizes one. Use when an existing Pod misbehaves, through the Runpod MCP tools:\n  its proxy URL answers 502, CUDA is not available inside the container, a restarted Pod has no GPU, the\n  user wants a Pod''s logs read, an account-wide check for stuck Pods, or the stop-versus-terminate decision\n  for a Pod they already have. Read-only until the user asks for an action.'\nmetadata:\n  author: runpod\n  version: \"2.0.0\" # x-release-please-version\n  concepts: [pod, machine, container-disk, pod-volume-disk, exposed-port, log-stream, gpu-availability, pod-migration]\nlicense: Apache-2.0\n---\n\n# Pod doctor\n\nYou operate an existing Pod: first diagnose what went wrong, then, only if the user asks for an action, perform the smallest safe recovery. Diagnosis is always read-only: no `update-pod`, `pod-action`, `delete-pod` or `create-pod` while diagnosing, whatever the logs suggest. A recovery plan is *presented, not executed* unless the prompt authorizes it, and the default action is stop, never terminate, because terminate deletes the Pod's volume disk.\n\nEvery diagnosis follows the same steps: read the Pod's state and logs before saying anything, quote the decisive line from the tool output, and never mutate a Pod the user did not name.\n\n## Tool binding\n\nThis skill reads before it acts. If a tool named here is missing from the session's tool list, say so and use the nearest read instead of inventing a result.\n\n| Capability | Tool |\n|---|---|\n| List Pods: the account-wide stuck audit and the \"which Pod\" resolution | `list-pods` |\n| Inspect one Pod: full status, ports, GPU count, mounts | `get-pod` |\n| Read Pod boot\u002Fcontainer logs: the model-load and crash evidence | `stream-pod-logs` (`source=system` for lifecycle events) |\n| Stop a Pod (keep the volume disk): gated | `pod-action` (`{\"action\":\"stop\"}`) |\n| Restart \u002F start a Pod: gated | `pod-action` (`{\"action\":\"restart\"}` \u002F `\"start\"`) |\n| Terminate a Pod: destructive, gated separately | `delete-pod` (or `pod-action` `{\"action\":\"terminate\"}`) |\n| GPU stock per data center, to recreate on infrastructure that has stock | `list-gpu-types` \u002F `get-gpu-type` (`include:[\"AVAILABILITY\"]`, `product:[\"POD\"]`) |\n| CUDA versions with capacity, per GPU type | the same read (`cudaVersions`); `get-capacity` for the matrix view |\n| Data centers | `list-data-centers` |\n| Recreate a Pod, only inside an authorized recovery | `create-pod` |\n\n## Phase 1 — diagnose (always, read-only)\n\nResolve the Pod the user named (or list Pods and match by name), then inspect it and read its logs before forming any conclusion. Classify against the symptom:\n\n- **Proxy 502 \u002F \"can't reach the web UI\".** Inspect the Pod. If its `status` is not `RUNNING`, that is the cause: the proxy has nothing to route to. If it is running, read the logs: a 502 through `\u003CpodId>-\u003Cport>.proxy.runpod.net` almost always means the app inside is bound to `127.0.0.1` (must bind `0.0.0.0`), listening on a port the Pod never exposed, still starting, or never started at all (no process on the exposed port). Quote the bind\u002Flisten line. The exposed ports are on the Pod record; name the mismatch, do not guess. A `524` is different: the proxy closes requests that run longer than 100 s, so it means a long request, not a dead app. For an app that never started, the answer is the diagnosis plus the exact change the user would apply (the start command, the env, the restart), marked \"not applied\".\n- **`torch.cuda.is_available()` is False.** Inspect the Pod record's `gpu` block, which carries the GPU count. If the block is absent or its count is 0, treat the Pod as CPU-only: this is a zero-GPU allocation, not a CUDA problem; go to the next classifier. If it shows one or more GPUs, the GPU is attached but the container can't use it: read the logs for the driver\u002Fruntime line. The usual causes are an image CUDA version newer than the host driver supports, or a CPU-only \u002F mismatched torch build. Quote the line; do not assert which without it.\n- **No GPU after a restart.** A stopped Pod releases its GPU but stays bound to its machine and resumes there. If another renter took that machine's GPU in the meantime, a plain start is refused for lack of a free GPU on that host, or the Pod comes back `RUNNING` without a GPU. Confirm it from the Pod record (the `gpu` block absent or its count 0, so the Pod is CPU-only) and say what it means: the GPU on that one machine is taken. Data-center stock for the GPU type does not predict whether this Pod gets its GPU back, so quote availability only when proposing a fresh Pod elsewhere. This is a placement problem, not a broken Pod. Give the user the concrete recoveries, not only a retry: (1) retry start until that machine's GPU frees; (2) migrate the Pod from the console, or recreate it on a GPU type or data center with live stock (a migrated or recreated Pod gets a new id and proxy URL); (3) **data rescue from a zero-GPU pod**: a pod started with 0 GPUs still runs and serves its filesystem, so the files are reachable with no GPU attached. No MCP tool moves bytes, so name the real path for the copy itself and hand it to the user: `runpodctl send` \u002F `runpodctl receive`, `aws s3` against a network volume's S3 endpoint, or `scp`\u002F`rsync` over the Pod's direct SSH (`ssh.direct`) (see [runpod-mcp\u002Freference\u002Fapi-boundary.md](..\u002Frunpod-mcp\u002Freference\u002Fapi-boundary.md)). Never claim the rescue needs a GPU first, and never claim to have copied anything yourself. Never terminate; that deletes the volume disk.\n- **Read the logs for a load or startup answer.** Read the Pod's logs with a generous tail (`source=system` for the pull, create and start events when the Pod is stuck in `STARTING`). Quote the single decisive line: the weights-loaded \u002F \"running on 0.0.0.0:PORT\" success line, or the OOM \u002F missing-file \u002F auth failure. Report what the log says, never what it probably says.\n- **Account-wide stuck audit.** List all Pods. Flag as stuck: `status=RUNNING` with no GPU (the Pod record's `gpu` block absent or its count 0); or stuck in `PROVISIONING`\u002F`STARTING` past about 10 minutes with no pull progress in the system log (a 20 GB image legitimately takes 10 to 15 minutes to pull). Present one table (name, requested GPU, status, stuck-for, reason). If nothing is stuck, say so in one line and stop. The counts in the summary must equal the rows in the table.\n\n**No RUNNING pod resolves (empty account, all pods stopped\u002Fexited, or wrong key).** If `list-pods` returns nothing, or returns only stopped\u002FEXITED pods none of which matches a live session the user describes, do not stop at \"give me a pod ID\" or \"which pod did you mean\". State what the list shows (no pods, or only stopped ones, by name) and the likely reason (stopped since the symptom, a different account\u002Fkey, or the pod was terminated). **Then commit to the most-common cause of that symptom and its concrete fix as the usual explanation**, and where the account\u002Fkey mismatch is a live possibility, ask which account they are on as the one follow-up:\n- Zero GPUs after restart → the usual cause is that another renter took the GPU on the machine the stopped Pod is bound to; recovery is to resume the Pod even at 0 GPUs so its files are reachable for a copy off (the copy runs through runpodctl or a volume's S3 endpoint; no MCP tool moves bytes), retry-start until that GPU frees, or migrate or recreate onto a machine with stock. Never terminate, which deletes the volume disk.\n- `torch.cuda.is_available()` False → the usual cause is the image's CUDA version being newer than the host driver (or a CPU-only\u002Fmismatched torch build); the host driver cannot change from inside the container, so the fix is to redeploy\u002Frecreate with a CUDA-version constraint (or a matching torch build).\n\nEnd phase 1 with the diagnosis and, if a fix exists, the *recommended* action, but do not run it. If the prompt was only \"why \u002F what's wrong \u002F is anything stuck\", you are done here.\n\n## Phase 2 — recovery (only if the user authorized an action)\n\nAdvance only when the prompt explicitly asks to stop, restart, recreate, or terminate a *named* Pod. A locked Pod refuses stop, terminate, edit and reset and keeps billing; the unlock is the user's step in the console.\n\n- **Stop vs terminate.** State the consequence before acting, every time: **stop** releases GPU\u002FCPU compute, moves the Pod to `EXITED`, clears the container disk, and keeps the volume disk (`\u002Fworkspace` by default), billed at the stopped-disk rate; stop is reversible with start, on the same machine. **Terminate** permanently deletes the Pod and its volume disk (a network volume is only detached, not deleted). When the user wants to stop paying for compute and keep the files, the answer is stop. Only terminate on an explicit \"delete \u002F terminate \u002F throw it away\", and say what disk dies.\n- **Restart \u002F re-acquire.** For a zero-GPU or hung Pod the user asked to recover, prefer stop→start (or restart) before any recreate; it is cheaper and non-destructive.\n- **Recreate on alternative infra.** Only if the user authorized a recreate. Capture the original config (image, GPU class, disk, ports, env, mounts, DC) from the Pod record and pick a GPU type and data center with real stock from the availability read. When the Pod mounts a network volume, the recreate stays in the volume's data center with the same volume, so pick a GPU type with stock there; moving to another data center is the user's call, so ask rather than choose it. Rescue anything on the volume disk first (terminate deletes it) and quote the log lines you need before terminating (a terminated Pod's logs are gone), then terminate + create. State the new Pod's hourly cost before creating it; a recreate is a billable resource. Never recreate a Pod whose original `image` is unavailable; skip and say so.\n\n## Hard rules\n\n- Never stop, restart, terminate, or recreate a Pod the user did not name. A stuck Pod may still hold state the user wants.\n- Default to stop. Terminate only on an explicit destructive instruction, and always after naming the disk that dies.\n- State the hourly cost before creating or recreating any Pod.\n- Never claim a recreate succeeded on the create call alone: a fresh Pod is created, not yet known healthy. Ask the user to re-run diagnosis to confirm.\n- Diagnosis quotes the log\u002Ffield it read. No \"probably\" about a fact the tool can answer.\n- If a log read or inspect call fails, report the failure and stop; do not guess the cause.\n\n## Error handling\n\n- A terminate\u002Fdelete returns `204` with no body. That is success, not an error.\n- A state-transition request that is invalid for the Pod's current status returns `409`. The Pod record's `actions` lists the permitted transitions; read it and pick a valid one.\n- A recreate that returns `no gpu available` means the chosen GPU\u002FDC also has no stock right now. Surface it and stop; do not silently retry elsewhere.\n\n## Contract\n\nThe cross-journey answer contract (definite facts from reads, commit-don't-hedge, mutations bind to this conversation's creations, a standalone final message, honest failure, granted tools only) is defined in the `runpod-mcp` skill and applies to every reply from this journey. If the `runpod-mcp` skill has not been loaded in this conversation, load it now, before the next tool call: its rules on which resources you may change, when a request is the go, and when to stop for the user are not repeated here.\n","# Pod doctor\n\nYou operate an existing Pod: first diagnose what went wrong, then, only if the user asks for an action, perform the smallest safe recovery. Diagnosis is always read-only: no `update-pod`, `pod-action`, `delete-pod` or `create-pod` while diagnosing, whatever the logs suggest. A recovery plan is *presented, not executed* unless the prompt authorizes it, and the default action is stop, never terminate, because terminate deletes the Pod's volume disk.\n\nEvery diagnosis follows the same steps: read the Pod's state and logs before saying anything, quote the decisive line from the tool output, and never mutate a Pod the user did not name.\n\n## Tool binding\n\nThis skill reads before it acts. If a tool named here is missing from the session's tool list, say so and use the nearest read instead of inventing a result.\n\n| Capability | Tool |\n|---|---|\n| List Pods: the account-wide stuck audit and the \"which Pod\" resolution | `list-pods` |\n| Inspect one Pod: full status, ports, GPU count, mounts | `get-pod` |\n| Read Pod boot\u002Fcontainer logs: the model-load and crash evidence | `stream-pod-logs` (`source=system` for lifecycle events) |\n| Stop a Pod (keep the volume disk): gated | `pod-action` (`{\"action\":\"stop\"}`) |\n| Restart \u002F start a Pod: gated | `pod-action` (`{\"action\":\"restart\"}` \u002F `\"start\"`) |\n| Terminate a Pod: destructive, gated separately | `delete-pod` (or `pod-action` `{\"action\":\"terminate\"}`) |\n| GPU stock per data center, to recreate on infrastructure that has stock | `list-gpu-types` \u002F `get-gpu-type` (`include:[\"AVAILABILITY\"]`, `product:[\"POD\"]`) |\n| CUDA versions with capacity, per GPU type | the same read (`cudaVersions`); `get-capacity` for the matrix view |\n| Data centers | `list-data-centers` |\n| Recreate a Pod, only inside an authorized recovery | `create-pod` |\n\n## Phase 1 — diagnose (always, read-only)\n\nResolve the Pod the user named (or list Pods and match by name), then inspect it and read its logs before forming any conclusion. Classify against the symptom:\n\n- **Proxy 502 \u002F \"can't reach the web UI\".** Inspect the Pod. If its `status` is not `RUNNING`, that is the cause: the proxy has nothing to route to. If it is running, read the logs: a 502 through `\u003CpodId>-\u003Cport>.proxy.runpod.net` almost always means the app inside is bound to `127.0.0.1` (must bind `0.0.0.0`), listening on a port the Pod never exposed, still starting, or never started at all (no process on the exposed port). Quote the bind\u002Flisten line. The exposed ports are on the Pod record; name the mismatch, do not guess. A `524` is different: the proxy closes requests that run longer than 100 s, so it means a long request, not a dead app. For an app that never started, the answer is the diagnosis plus the exact change the user would apply (the start command, the env, the restart), marked \"not applied\".\n- **`torch.cuda.is_available()` is False.** Inspect the Pod record's `gpu` block, which carries the GPU count. If the block is absent or its count is 0, treat the Pod as CPU-only: this is a zero-GPU allocation, not a CUDA problem; go to the next classifier. If it shows one or more GPUs, the GPU is attached but the container can't use it: read the logs for the driver\u002Fruntime line. The usual causes are an image CUDA version newer than the host driver supports, or a CPU-only \u002F mismatched torch build. Quote the line; do not assert which without it.\n- **No GPU after a restart.** A stopped Pod releases its GPU but stays bound to its machine and resumes there. If another renter took that machine's GPU in the meantime, a plain start is refused for lack of a free GPU on that host, or the Pod comes back `RUNNING` without a GPU. Confirm it from the Pod record (the `gpu` block absent or its count 0, so the Pod is CPU-only) and say what it means: the GPU on that one machine is taken. Data-center stock for the GPU type does not predict whether this Pod gets its GPU back, so quote availability only when proposing a fresh Pod elsewhere. This is a placement problem, not a broken Pod. Give the user the concrete recoveries, not only a retry: (1) retry start until that machine's GPU frees; (2) migrate the Pod from the console, or recreate it on a GPU type or data center with live stock (a migrated or recreated Pod gets a new id and proxy URL); (3) **data rescue from a zero-GPU pod**: a pod started with 0 GPUs still runs and serves its filesystem, so the files are reachable with no GPU attached. No MCP tool moves bytes, so name the real path for the copy itself and hand it to the user: `runpodctl send` \u002F `runpodctl receive`, `aws s3` against a network volume's S3 endpoint, or `scp`\u002F`rsync` over the Pod's direct SSH (`ssh.direct`) (see [runpod-mcp\u002Freference\u002Fapi-boundary.md](..\u002Frunpod-mcp\u002Freference\u002Fapi-boundary.md)). Never claim the rescue needs a GPU first, and never claim to have copied anything yourself. Never terminate; that deletes the volume disk.\n- **Read the logs for a load or startup answer.** Read the Pod's logs with a generous tail (`source=system` for the pull, create and start events when the Pod is stuck in `STARTING`). Quote the single decisive line: the weights-loaded \u002F \"running on 0.0.0.0:PORT\" success line, or the OOM \u002F missing-file \u002F auth failure. Report what the log says, never what it probably says.\n- **Account-wide stuck audit.** List all Pods. Flag as stuck: `status=RUNNING` with no GPU (the Pod record's `gpu` block absent or its count 0); or stuck in `PROVISIONING`\u002F`STARTING` past about 10 minutes with no pull progress in the system log (a 20 GB image legitimately takes 10 to 15 minutes to pull). Present one table (name, requested GPU, status, stuck-for, reason). If nothing is stuck, say so in one line and stop. The counts in the summary must equal the rows in the table.\n\n**No RUNNING pod resolves (empty account, all pods stopped\u002Fexited, or wrong key).** If `list-pods` returns nothing, or returns only stopped\u002FEXITED pods none of which matches a live session the user describes, do not stop at \"give me a pod ID\" or \"which pod did you mean\". State what the list shows (no pods, or only stopped ones, by name) and the likely reason (stopped since the symptom, a different account\u002Fkey, or the pod was terminated). **Then commit to the most-common cause of that symptom and its concrete fix as the usual explanation**, and where the account\u002Fkey mismatch is a live possibility, ask which account they are on as the one follow-up:\n- Zero GPUs after restart → the usual cause is that another renter took the GPU on the machine the stopped Pod is bound to; recovery is to resume the Pod even at 0 GPUs so its files are reachable for a copy off (the copy runs through runpodctl or a volume's S3 endpoint; no MCP tool moves bytes), retry-start until that GPU frees, or migrate or recreate onto a machine with stock. Never terminate, which deletes the volume disk.\n- `torch.cuda.is_available()` False → the usual cause is the image's CUDA version being newer than the host driver (or a CPU-only\u002Fmismatched torch build); the host driver cannot change from inside the container, so the fix is to redeploy\u002Frecreate with a CUDA-version constraint (or a matching torch build).\n\nEnd phase 1 with the diagnosis and, if a fix exists, the *recommended* action, but do not run it. If the prompt was only \"why \u002F what's wrong \u002F is anything stuck\", you are done here.\n\n## Phase 2 — recovery (only if the user authorized an action)\n\nAdvance only when the prompt explicitly asks to stop, restart, recreate, or terminate a *named* Pod. A locked Pod refuses stop, terminate, edit and reset and keeps billing; the unlock is the user's step in the console.\n\n- **Stop vs terminate.** State the consequence before acting, every time: **stop** releases GPU\u002FCPU compute, moves the Pod to `EXITED`, clears the container disk, and keeps the volume disk (`\u002Fworkspace` by default), billed at the stopped-disk rate; stop is reversible with start, on the same machine. **Terminate** permanently deletes the Pod and its volume disk (a network volume is only detached, not deleted). When the user wants to stop paying for compute and keep the files, the answer is stop. Only terminate on an explicit \"delete \u002F terminate \u002F throw it away\", and say what disk dies.\n- **Restart \u002F re-acquire.** For a zero-GPU or hung Pod the user asked to recover, prefer stop→start (or restart) before any recreate; it is cheaper and non-destructive.\n- **Recreate on alternative infra.** Only if the user authorized a recreate. Capture the original config (image, GPU class, disk, ports, env, mounts, DC) from the Pod record and pick a GPU type and data center with real stock from the availability read. When the Pod mounts a network volume, the recreate stays in the volume's data center with the same volume, so pick a GPU type with stock there; moving to another data center is the user's call, so ask rather than choose it. Rescue anything on the volume disk first (terminate deletes it) and quote the log lines you need before terminating (a terminated Pod's logs are gone), then terminate + create. State the new Pod's hourly cost before creating it; a recreate is a billable resource. Never recreate a Pod whose original `image` is unavailable; skip and say so.\n\n## Hard rules\n\n- Never stop, restart, terminate, or recreate a Pod the user did not name. A stuck Pod may still hold state the user wants.\n- Default to stop. Terminate only on an explicit destructive instruction, and always after naming the disk that dies.\n- State the hourly cost before creating or recreating any Pod.\n- Never claim a recreate succeeded on the create call alone: a fresh Pod is created, not yet known healthy. Ask the user to re-run diagnosis to confirm.\n- Diagnosis quotes the log\u002Ffield it read. No \"probably\" about a fact the tool can answer.\n- If a log read or inspect call fails, report the failure and stop; do not guess the cause.\n\n## Error handling\n\n- A terminate\u002Fdelete returns `204` with no body. That is success, not an error.\n- A state-transition request that is invalid for the Pod's current status returns `409`. The Pod record's `actions` lists the permitted transitions; read it and pick a valid one.\n- A recreate that returns `no gpu available` means the chosen GPU\u002FDC also has no stock right now. Surface it and stop; do not silently retry elsewhere.\n\n## Contract\n\nThe cross-journey answer contract (definite facts from reads, commit-don't-hedge, mutations bind to this conversation's creations, a standalone final message, honest failure, granted tools only) is defined in the `runpod-mcp` skill and applies to every reply from this journey. If the `runpod-mcp` skill has not been loaded in this conversation, load it now, before the next tool call: its rules on which resources you may change, when a request is the go, and when to stop for the user are not repeated here.\n",{"name":5,"license":15,"metadata":48,"description":7},{"author":9,"version":49,"concepts":50},"2.0.0",[51,52,53,54,55,56,57,58],"pod","machine","container-disk","pod-volume-disk","exposed-port","log-stream","gpu-availability","pod-migration","main","91b9f9671af0f15186420ec466fe6e80c1b13f25","plugins\u002Frunpod\u002Fskills\u002Frunpod-pod-doctor",10,"https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official","https:\u002F\u002Fdocs.runpod.io\u002Fagent-setup.md","https:\u002F\u002Fgithub.com\u002Frunpod","https:\u002F\u002Fwww.runpod.io","2026-11-10 06:32:38",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add runpod\u002Frunpod-plugins-official --skill runpod-pod-doctor",{"tool":74,"command":75},"bunx","bunx skills add runpod\u002Frunpod-plugins-official --skill runpod-pod-doctor",{"tool":77,"command":78},"pnpm","pnpm dlx skills add runpod\u002Frunpod-plugins-official --skill runpod-pod-doctor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-pod-doctor\u002FSKILL.md",true,[],[83,111,129,146,166,185],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":95,"publishedAt":43},"01M717A4HFW93XQC7PTXV1QFFH","runpod-vllm","Serve a Hugging Face model with vLLM on Runpod (Hub worker-vllm queue endpoint, load-balancing endpoint on a vllm\u002Fvllm-openai image, or a Pod), sized, CUDA-pinned and verified with a real OpenAI client. Use for any \"deploy\u002Fserve\u002Ftest this LLM with vLLM\" request or a vLLM deployment that will not boot; defer to runpod-serverless-deploy for non-vLLM engines and runpod-endpoint-ops for an endpoint that already works.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-vllm\u002FSKILL.md",[89,92],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[96,9,97,42,98,99,100,34,33,101,102,103,104,105,106,107,108,28,109,110],"runpod vllm","vLLM","model","worker","image","request","release","network","verified","hugging face","openai","face","endpoint","load-balancing","for",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":43},"01M6CFW2PPRQZ006AVQXGMWPH1","runpodctl","Runpod CLI for managing GPU\u002FCPU workloads from the terminal — pods, serverless endpoints, templates, network volumes, Hub deploys, models, SSH, and file transfer (send\u002Freceive, network-volume upload\u002Fdownload). Use for terminal\u002FCI\u002Fscripting, SSH setup, `doctor`, or when the Runpod MCP tools are not connected; prefer runpod-mcp for structured tool calls in an MCP-enabled session.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpodctl\u002FSKILL.md",[117],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[113,24,98,119,39,120,121,122,42,123,124,103,9,125,30,126,108,127,128,27],"ci","Bash","cli","template","CPU","terminal","ssh setup","macos","send","windows",{"skillNo":130,"name":9,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":135,"publishedAt":43},"01M6CFVTW32TE82Y5NA85H83CK","Start here when the Runpod lane is unclear: picks the skill for a task (runpod-mcp and the journey playbooks it routes to, such as runpod-serverless-deploy, runpod-pod-deploy, runpod-pod-doctor and runpod-cost-audit; runpodctl, runpod-flash, runpod-companion-clis, runpod-usage, runpod-templates, runpod-build-template, runpod-migrate) and indexes two dozen end-to-end worked examples (golden paths). Use it before any multi-step or provisioning task, even when the lane is clear, to check for a matching golden path; for the Runpod MCP tools, runpod-mcp owns the answer contract, connection and tool rules.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod\u002FSKILL.md",[134],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[9,39,136,122,103,137,42,138,139,140,141,142,108,143,144,30,145,113,24,27],"migrate","start","end","companion","paths","flash","golden","journey","audit","path",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":153,"publishedAt":43},"01M6CFVK41CSZ4HM1N7TKM3WWY","runpod-usage","Explain Runpod architecture and design choices: Pods versus Serverless, GPU\u002FVRAM, image construction, storage, networking, and workload development. For creating or improving a complete template project use runpod-build-template; execute infrastructure with runpodctl\u002Frunpod-mcp and code-first work with runpod-flash.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-usage\u002FSKILL.md",[152],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[154,9,155,113,156,157,158,39,159,100,160,161,162,36,42,110,163,164,99,165],"runpod usage","usage","development","container","design","use","code","explain","architecture","project","complete","vram",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":173,"publishedAt":43},"01M6CFVEPPADDF61NC3MC4KCE5","runpod-templates","Find, use, and troubleshoot official Runpod Pod templates, including ComfyUI workflow model metadata repair. For creating or optimizing Dockerfiles and application template projects use runpod-build-template; deploy through runpod-mcp or runpodctl.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-templates\u002FSKILL.md",[172],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[174,175,9,113,176,177,178,98,179,39,180,100,120,122,33,181,182,183,184,110],"runpod templates","templates","projects","python3","official","inventory","workflow","scripts","troubleshoot","png","repair",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":194,"publishedAt":43},"01M6PP9W1XMN6PT4J4H0XEMTKW","runpod-serverless-deploy","Bring any source (a HuggingFace repo, a ComfyUI workflow, a Hub release, a custom container image, a GGUF repo, a Civitai asset, or a community template) to a proven Runpod Serverless endpoint: pick the engine for the modality and model format, size the GPU from the model's real metadata, provision, warm, prove it with one real job, and hand back the URL with what it bills. Deploys an existing source through the Runpod MCP tools; code-first Python deploys (the Flash dev loop) are out of scope. Use when the user wants a model or worker served on Runpod Serverless, whatever the modality: text generation, speech-to-text or text-to-speech, image or video generation, embeddings, document processing, or their own handler image. For an LLM served with vLLM (Hub worker-vllm, a vllm\u002Fvllm-openai image, or a vLLM Pod), defer to runpod-vllm.","https:\u002F\u002Fgithub.com\u002Frunpod\u002Frunpod-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Frunpod\u002Fskills\u002Frunpod-serverless-deploy\u002FSKILL.md",[191,192,193],{"categoryNo":90,"categoryName":91,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[195,9,196,197,198,199,200,201,42,202,203,98,204,99,39,205,37,180,100,27],"runpod serverless deploy","serverless deploy","deploy","serverless","back","Video","community","processing","scope","pick","loop"]