pod/skills/pod/SKILL.md
--- name: pod description: Schema reference for `kind: pod` and `kind: deploy` entities — deploy.yml entry shape, nested deploys, sidecars, pod networking. For verb-level operations see /ov-core:deploy. --- # `kind: pod` and `kind: deploy` — Schema Reference This skill is a thin schema pointer. For runtime verbs (`ov deploy add`, `ov deploy del`, `ov update`), see `/ov-core:deploy`. ## What lives in `kind: pod` / `kind: deploy` A `pod` entity declares a co-scheduled set of containers and the
npx skillsauth add overthinkos/overthink-plugins pod/skills/podInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
kind: pod and kind: deploy — Schema ReferenceThis skill is a thin schema pointer. For runtime verbs (ov deploy add, ov deploy del, ov update), see /ov-core:deploy.
kind: pod / kind: deployA pod entity declares a co-scheduled set of containers and the volumes / network / sidecars they share. A deploy entity is the bind site — it picks an image (or image+layers), maps it onto a target (pod, local, vm, k8s), and stores the runtime knobs (encrypted volumes, tunnels, env, ports).
Schema sources (read these for the canonical truth):
ov/deploy_spec.go — DeploySpec Go type, kind: deploy shape, target discriminator.ov/pod_spec.go — PodSpec Go type, kind: pod shape./ov-core:deploy — the verb-level skill covering ov deploy add / ov deploy del / ov update.deploy entries can nest via nested:. A parent deploy and its nested entries share the pod and the tunnel; each nested entry is a separate quadlet/process inside the same pod namespace.
sidecar: declares co-running containers with their own env-var routing (env_accepts / env_requires). See /ov-automation:sidecar for the topic skill.
/ov-core:deploy, /ov-core:ov-update, /ov-core:remove./ov-image:image, /ov-vm:vm, /ov-kubernetes:kubernetes, /ov-local:local-spec./ov-automation:sidecar, /ov-automation:enc.development
Claude Code multi-agent support in Overthink — sub-agents, dynamic workflows, and agent teams, and how each drives the existing `ov eval` disposable beds to test and verify. MUST be invoked before authoring or invoking an ov sub-agent / dynamic workflow / agent team, wiring agent-lifecycle hooks, or asking "which primitive should drive the R10 beds?".
tools
Mounts a virtiofs share tagged `workspace` at /workspace inside a VM guest via a systemd .mount unit. Use when a kind:vm entity shares a host directory into the guest and you need it auto-mounted (and re-mounted at every boot).
development
MUST be invoked before any work involving: the `kind: android` schema kind, a `target: android` deploy, the `apk:` layer package format (installing Android apps declaratively), AndroidDeployTarget, an in-pod emulator OR a remote/physical adb-endpoint device, or nested `pod → android` deployment. The first-class Android device + app surface that sits above `ov eval adb`/`appium`.
tools
Use when committing, branching, pushing, merging, tagging, creating PRs, or approving/merging PRs with gh — the feat/-branch, R10-gated, never-force-push landing workflow across the main repo + the plugins submodule + image/<distro> submodules. Covers sync-to-upstream, branch/worktree pruning, the fork+PR path for contributors without write access, and cross-repo @github landing order.