Spins up and manages ephemeral Linux containers for isolated builds and testing.
Install
mkdir -p .claude/skills/pu && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/17312" && unzip -o skill.zip -d .claude/skills/pu && rm skill.zipInstalls to .claude/skills/pu
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Provision and drive a `pu` box — an Incus container used as a clean Linux host for CI, builds, and evidence capture. Use when you need to run something on a fresh remote box instead of the user's machine: `nix run` a build, run CI against a real host, capture screenshots/video off-machine, or reproduce on a pristine environment. Covers create/connect/scp/destroy, running remote commands, copying artifacts back, and the no-egress failure mode. Triggers on "pu box", "spin up a box", "run this on a box", "ephemeral host", "pu create/connect/destroy".Key capabilities
- →Create Incus containers as clean NixOS hosts
- →Connect to a `pu` box via SSH to run commands
- →Copy files to and from a `pu` box using scp
- →Destroy `pu` boxes when no longer needed
- →Poll for service health on a `pu` box
- →Troubleshoot network egress issues on `pu` boxes
How it works
The skill provisions Incus containers as clean NixOS hosts, allowing users to connect via SSH to execute commands, copy files, and manage the container's lifecycle. It uses `pu` commands for these operations.
Inputs & outputs
When to use pu
- →Running builds off-machine
- →Ephemeral CI testing
- →Reproducible environment setup
About this skill
pu — on-demand Incus boxes
pu hands out Linux containers. Each box is a clean NixOS host with Nix
- flakes, reachable over SSH through
pu's own proxy. Use one whenever work should run off the user's machine — a CI run, anix runbuild, evidence capture — so nothing local is at risk and the environment is reproducible. A box can be short-lived (spin up, use,destroy) or kept around long-term — the lifetime is yours to choose.
Lifecycle
pu create "$host" # create; writes ~/.pu-state/$host/ssh_config
pu list # NAME + LOCATION (the physical host it landed on)
pu connect "$host" # interactive ssh
pu connect "$host" -- CMD # run CMD on the box and return
pu destroy "$host" # tear down — always do this when finished
Name is positional. Pick a descriptive, collision-free name (e.g. app-pr-42-evidence).
pu connect is the reliable way in — it reads ~/.pu-state/$host/ssh_config itself, so it
needs no setup. Bare ssh "$host" works only if you've added Include ~/.pu-state/*/ssh_config to ~/.ssh/config (optional, often not set up); otherwise use
pu connect, or pass the config explicitly: ssh -F ~/.pu-state/$host/ssh_config "$host".
Run commands on the box
# One-shot
pu connect "$host" -- 'uname -a'
# Background a long-running server (nohup so it survives the SSH session)
pu connect "$host" -- "nohup nix run github:owner/app -- --port 8080 >/tmp/app.log 2>&1 &"
# Poll until it's healthy
pu connect "$host" -- 'until curl -sf http://127.0.0.1:8080/health; do sleep 2; done'
The box has its own loopback — bind servers to 127.0.0.1 on whatever port you
like; there is no clash with anything on the user's machine.
Copy artifacts back
pu connect is SSH, so scp works against the box's generated config:
scp -F ~/.pu-state/"$host"/ssh_config "$host":/tmp/out.png /tmp/out.png
Failure mode: no outbound network
A box occasionally lands on a host with broken egress — DNS and even raw-IP TCP
time out, so nix run github:... hangs on "Resolving timed out". This is
host-specific, not your fault. Probe egress first; if it fails, destroy and
recreate (a fresh box usually lands on a healthy host):
pu connect "$host" -- 'timeout 15 curl -sS -o /dev/null -w "%{http_code}\n" https://api.github.com' \
|| { echo "no egress — recreating"; pu destroy "$host"; pu create "$host"; }
If retries keep landing on dead hosts, capture diagnostics for the admin — the box's
LOCATION from pu list, /etc/resolv.conf, ip route, and a /dev/tcp connect
test to the gateway and to a raw IP — and hand them over (e.g. a gist).
When not to use it
- →When work should run on the user's local machine
- →When a persistent, non-ephemeral host is required without the option to destroy
- →When the task does not involve CI, builds, or evidence capture
Limitations
- →The `pu` box has no outbound network by default if it lands on a host with broken egress
- →Bare `ssh "$host"` works only if `~/.ssh/config` is set up to include `~/.pu-state/*/ssh_config`
- →The box has its own loopback, so services bind to `127.0.0.1`
How it compares
This skill provides an isolated, reproducible environment for running tasks off the user's machine, unlike executing directly on the local system which can introduce inconsistencies or risks.
Compared to similar skills
pu side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| pu (this skill) | 0 | 29d | Caution | Intermediate |
| deployment-engineer | 4 | 3mo | No flags | Advanced |
| devops-engineer | 1 | 2mo | Review | Advanced |
| devops-engineer | 0 | 3mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by srid
View all by srid →You might also like
deployment-engineer
sickn33
Expert deployment engineer specializing in modern CI/CD pipelines, GitOps workflows, and advanced deployment automation. Masters GitHub Actions, ArgoCD/Flux, progressive delivery, container security, and platform engineering. Handles zero-downtime deployments, security scanning, and developer experience optimization. Use PROACTIVELY for CI/CD design, GitOps implementation, or deployment automation.
devops-engineer
Jeffallan
Use when setting up CI/CD pipelines, containerizing applications, or managing infrastructure as code. Invoke for pipelines, Docker, Kubernetes, cloud platforms, GitOps.
devops-engineer
I-Synergy
DevOps and CI/CD specialist. Use for building pipelines, containerization, infrastructure as code, or deployment automation. User-invocable only for production deployments.
platform-engineering
villadalmine
>-
add-linux-bootstrap-platform
ponylang
Load when adding a new Linux distro/version (e.g. Alpine 3.24, Ubuntu 26.04) — or both arches for an existing one — as a fully supported ponyup bootstrap-test target. Covers the bootstrap-tester Dockerfile, image build dispatch and tag discovery, CI workflow updates (tier 1 / tier 2), ponyup-init.sh
production-dockerfile
phenobarbital
Generate production-ready Dockerfiles with multi-stage builds, security best practices, and optimization. Use when containerizing Python applications for production deployment.