write-guide
Write or change a skill, reference doc or golden path in this repo so it agrees with the concept graph and is linked to it. Use when adding or editing any SKILL.md, reference/*.md or golden path, and after adding or changing a concept so the docs that cover it are updated too. Pairs with the add-concept skill, which covers the concept files themselves.
- License 许可
- Apache-2.0
- 最近更新
- 2026-11-12
- Stars
- ★ 49
- Forks
- 10
01 前言 Front Matter
- name
- write-guide
- metadata
- { "internal": true }
- description
- Write or change a skill, reference doc or golden path in this repo so it agrees with the concept graph and is linked to it. Use when adding or editing any SKILL.md, reference/*.md or golden path, and after adding or changing a concept so the docs that cover it are updated too. Pairs with the add-concept skill, which covers the concept files themselves.
03 SKILL.md 正文
Write a guide against the concept graph
This repo has two kinds of content that must agree:
- Concepts (
plugins/runpod/skills/runpod-usage/concepts/*.yaml) hold exact facts as rules, each citing a public source. They are the source of truth for what is true. - Guides (every
SKILL.md,reference/*.mdand golden path) explain, teach and demonstrate. They are the source of truth for how to do it.
A guide states facts that the concept rules support, and links to the concepts it covers.
A concept is covered by at least one guide. pnpm check:guides enforces both links.
Writing or changing a guide
-
Find the concepts it touches before writing (run these in
ontology/tools/):pnpm build:sqlite pnpm query tree "<concept>" # the concept, its children and the guides that cover them pnpm query search "<question>" # the rules that answer a question pnpm query concept "<name>" # every rule on one concept, with evidence -
Write from the rules. Every factual claim (a limit, a default, a state, what an action does, what exists) must match a rule. Explain it in your own words and add the how: the commands, order, pitfalls and verification.
- If the guide needs a fact that no rule has, add the rule first with the
add-conceptskill, citing the spec, the public docs or a live probe. Then write the guide. - If a rule is wrong or out of date, fix the rule (and its evidence) in the same change.
- Never let a guide and a rule say different things. If you find a disagreement, the public source decides which one changes.
- If the guide needs a fact that no rule has, add the rule first with the
-
Declare the links.
Guide Where Example SKILL.mdmetadata.conceptsin the frontmatterconcepts: [pod, network-volume]Reference doc a concepts:line in frontmatter at the top---<br>concepts: [runpod-secret]<br>---Golden path lanes,mcp,concepts,status,verifiedandevalsin frontmatter, plus the matching> **Status:**line under the titlesee plugins/runpod/skills/runpod/golden-paths/README.mdList the concepts the guide actually explains or uses, not every word it mentions.
pnpm build:bundle --suggestlists the concepts each golden path names, as candidates. A reference doc that a rule already cites as evidence is linked automatically, but list its concepts anyway when it covers more than the citing rules. -
Point to the rules when a doc is the main explanation of a concept. End it with a short "Exact rules" section with a Markdown link to each concept file (from a reference doc the target is
../concepts/<id>.yaml). -
Route it. A new reference doc gets a row in its skill's
SKILL.mdtable. A new golden path gets rows in the router's table andgolden-paths/README.md.
After adding or changing a concept
-
pnpm check:guidesfails if the new concept has no guide. Extend an existing doc or write a new one, following the steps above. -
Find the guides that already cover it and check they still agree with the rules:
pnpm query tree "<concept>" # guides linked to it grep -rln "<name or alias>" ../../plugins/ # guides that mention it without a link -
When a rule cites a skill file as evidence and you change that file, re-read the rule:
grep -rn "<path>" ../../plugins/runpod/skills/runpod-usage/concepts/.
Style
Follow plugins/runpod/skills/runpod-usage/concepts/README.md → "Writing style" and the
repo conventions in AGENTS.md: plain present tense, "Runpod", code identifiers in
backticks, no "currently" or "not yet", and positive claims over claims that something is
missing (a missing capability needs the spec or docs as evidence, and CLI absence claims are
checked by hooks/check_cli_absence_claims.py).
Check
cd ontology/tools
pnpm format && pnpm validate --strict && pnpm check:guides && pnpm scan && pnpm test
cd ../.. && python3 hooks/check_links.py && python3 hooks/check_runpod_branding.py
check:guides must report no errors, and the build line "concepts with a guide" must stay at
every concept.
04 同仓库更多 Skills
runpod-vllm
Serve a Hugging Face model with vLLM on Runpod (Hub worker-vllm queue endpoint, load-balancing endpoint on a vllm/vllm-openai image, or a Pod), sized, CUDA-pinned and verified with a real OpenAI client. Use for any "deploy/serve/test 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.
runpodctl
Runpod CLI for managing GPU/CPU workloads from the terminal — pods, serverless endpoints, templates, network volumes, Hub deploys, models, SSH, and file transfer (send/receive, network-volume upload/download). Use for terminal/CI/scripting, SSH setup, `doctor`, or when the Runpod MCP tools are not connected; prefer runpod-mcp for structured tool calls in an MCP-enabled session.
runpod
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.
runpod-usage
Explain Runpod architecture and design choices: Pods versus Serverless, GPU/VRAM, image construction, storage, networking, and workload development. For creating or improving a complete template project use runpod-build-template; execute infrastructure with runpodctl/runpod-mcp and code-first work with runpod-flash.
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.
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/vllm-openai image, or a vLLM Pod), defer to runpod-vllm.