Yeet

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:

1. https://yeetrun.com/docs for product docs, workflows, concepts, and CLI docs
2. https://github.com/yeetrun/yeet for implementation details, behavior verification, and code paths
3. 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:

1. product guidance
2. workflow selection
3. 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