| name | yeet |
| description | Use when working with yeet or catch: installation, configuration, command selection, workflow guidance, or troubleshooting for the personal homelab deployment tool. Retrieval-first: prefer yeetrun.com docs and the yeetrun/yeet repo; use local sibling checkouts when available for local verification. |
Yeet
yeet is personal homelab tooling. Preserve that framing. Do not flatten it
into a generic deployment platform.
Sources of Truth
Use these sources in this order:
https://yeetrun.com/docs for product docs, workflows, concepts, and CLI
docs
https://github.com/yeetrun/yeet for implementation details, behavior
verification, and code paths
- repo-local reference notes for this skill, when present, for quick
orientation only
If local sibling checkouts such as ~/code/yeet/website and ~/code/yeet
exist, prefer them for local verification because they are easier to inspect,
but treat them as an optional developer convenience rather than a public
requirement.
If the docs and implementation appear to disagree, treat the repo code as the
final authority for current behavior and say so explicitly.
When to Use
Use this skill when the user asks about:
- installing
yeet
- choosing a
yeet or catch workflow
- understanding host targeting, service types, or Tailscale assumptions
- diagnosing failed
yeet or catch behavior
- mapping an operational goal onto the right
yeet command path
Default Approach
Start by classifying the request:
- product guidance
- workflow selection
- troubleshooting
Then route to the right source before answering.
Product Guidance
For product and usage questions:
- start with
skills/yeet/references/source-map.md for the public doc and repo
lookup map
- use
https://yeetrun.com/docs/getting-started/installation for setup
- use
https://yeetrun.com/docs/getting-started/quick-start for the shortest
happy path
- use
https://yeetrun.com/docs/operations/workflows for operator flows
- use
https://yeetrun.com/docs/cli/yeet-cli and
https://yeetrun.com/docs/cli/catch-cli for CLI specifics
Answer in real yeet terms. Keep yeet and catch distinct.
Workflow Selection
Map the user's goal to the actual artifact and host model before suggesting a
command. Use skills/yeet/references/workflows.md as the canonical companion
for the host bootstrap note and deployment-path examples, and
skills/yeet/references/boundaries.md for host-model cautions.
Also verify whether the user means the SSH machine host or the catch host,
whether --env-file is part of the workflow, and whether Tailscale setup is
required.
Troubleshooting Flow
Use skills/yeet/references/troubleshooting.md as the canonical companion for
the default debug order and first failure domains. Inspect implementation
details only where the docs are incomplete or the observed behavior diverges.
Use skills/yeet/references/source-map.md for the public doc and repo lookup
paths that support that investigation.
When To Inspect Code
Inspect the yeetrun/yeet repository when you need:
- behavior verification for CLI flags or command routing
- troubleshooting details not spelled out in the docs
- clarification when docs and observed behavior diverge
Bias toward these areas, using local sibling checkouts when available and the
public GitHub paths from skills/yeet/references/source-map.md otherwise:
cmd/yeet
cmd/catch
pkg/yeet
pkg/catch
Boundaries
- Preserve the current project stance that this is personal homelab tooling.
- Warn when advice depends on the author's environment, trust model, or host
topology.
- Do not promise general-purpose compatibility the project does not claim.
- Use
skills/yeet/references/boundaries.md as the canonical companion for the
host model and assumption checks behind that framing.
Local References
Use repo-local reference notes only when they are actually present in this
skill. Treat them as compact companion notes for the skill, not a replacement
for the primary docs or codebase.
skills/yeet/references/boundaries.md
skills/yeet/references/source-map.md
skills/yeet/references/workflows.md
skills/yeet/references/troubleshooting.md