使用方法
- 复制安装命令，在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物，并对照来源检查输出。
npx skills add https://github.com/runpod/runpod-plugins-official --skill runpod-usage开始前需了解
- 安装不包含模型订阅、API 额度或访问文件的权限。
- 仓库星数和安装量反映活跃情况，不等于独立质量或安全测试。
按源仓库内容呈现，保留标题、案例、代码、表格、链接以及原文引用的演示图片。
Runpod usage (concepts)
Background knowledge for making the right choice before you act. This skill runs nothing — once you know what to do, execute with runpod-mcp/runpodctl (infra), flash (your own code), or companion-clis (models/images/data).
This skill explains; the golden paths demonstrate. When the question is really "how do I do X" rather than "how does X work", the verified end-to-end example is the faster answer — runpod/golden-paths/README.md. Read the concept here, then follow the path.
To author files for a custom template, use runpod-build-template; this lane supplies the shared concepts, not a competing packaging workflow.
Read the one reference file that matches the question:
| Question | Read |
|---|---|
First-run setup / auth — get + set RUNPOD_API_KEY, SSH, companion creds | reference/getting-started.md |
| Pods vs serverless, workers, cold starts, FlashBoot, queue vs load-balanced | reference/concepts.md |
| The development loop for ANY workload (start here) — plan → prefer prebuilt → provision → verify → teardown | reference/development-loop.md |
| Stand up / iterate a workload on a pod — the pod sub-loop | reference/pod-workflows.md |
| Deploy / iterate a serverless endpoint — Hub vs flash vs custom, invoke + verify | reference/endpoint-workflows.md |
Install software on a pod — package hygiene, uv, non-interactive, caching | reference/on-pod-setup.md |
Build a Docker image Runpod can run (handler contract, Dockerfile, --platform=linux/amd64) | reference/docker.md |
| How to build an image well — base image, layering, bake-in vs volume, pod vs serverless (queue/LB) contract | reference/building-images.md |
| Where data lives — container disk vs network volume, model caching, S3 access | reference/storage.md |
| Which GPU / how much VRAM / which CUDA version / cost & availability / data centers | reference/gpu-selection.md |
| Why a stopped pod may not restart with a GPU — pods are bound to one machine; what else is per machine | reference/pods-and-machines.md |
| Endpoint releases, rolling updates, version overlap, GitHub builds | reference/endpoint-builds-and-releases.md |
| Storing API tokens and keys as secrets and referencing them from env vars | reference/secrets.md |
| Reaching a pod or endpoint over HTTP (proxy URLs, exposed ports) | reference/networking.md |
| Common mistakes and how to avoid them | reference/gotchas.md |
Exact facts: the concept files
The reference files explain. For a precise fact, or a rule an action must satisfy, read the concept files in concepts/ next to this file. There is one YAML file per concept (pod.yaml, network-volume.yaml, machine.yaml, …), each with its fields, states, relations and rules, and every rule cites the public source it comes from.
grep -il "volume disk" concepts/*.yaml # find the concept by name or alias
grep -n "statement:" concepts/pod-volume-disk.yamlrules[].statementis the fact.see:points at related rules on other concepts.- A rule with
conflict: truerecords two public sources that disagree. Give both readings. - A
kind: processfile explains a flow step by step.pod-deployment.yamlcovers deploy,
stop and restart, including why a restart can fail while the data center has stock.
