Skip to main content
Skills are reusable workflows an AI coding agent can invoke by name. boxd ships six of them: one for everyday CLI usage, four for “wire-it-up-once” automation (golden VM, deploy on push, per-PR previews, agent-driven fix), and one that installs the Hermes agent on a VM. The agent reads a short instruction file, runs the steps, and asks you to confirm before making any changes. You get the skills two ways, depending on where your agent runs:
  • On your laptop — they ship with the boxd CLI; install once and they drive a remote golden over the API.
  • Inside a boxd VM — they’re baked into every VM image, already at ~/.claude/skills/ with nothing to install, and they drive the in-VM CLI. See Inside a VM.
Currently only Claude Code is supported. The skills install at ~/.claude/skills/ and use Claude Code’s skill format. If you’d like the same workflows packaged for another agent (Codex, Cursor, OpenCode, …), reach out and we’ll prioritize.

​
What you get

​
Install

This is the laptop path. Inside a boxd VM the skills already ship in the image — there’s nothing to install. Skip to Inside a VM.
On your laptop, all six skills ship with the boxd CLI. The same installer drops both the binary and the skills:
What lands on disk:
  • boxd-cli skill → ~/.claude/skills/boxd-cli/SKILL.md
  • boxd-setup-{golden,deploy,preview,fix} skills → ~/.claude/skills/boxd-setup-*/ (each with its own SKILL.md plus an assets/ directory of templates the agent renders during setup)
  • boxd-setup-hermes skill → ~/.claude/skills/boxd-setup-hermes/SKILL.md (just the instruction file — it drives Hermes’ own installer, no templates)
Re-run the installer any time to upgrade — it pulls the latest version of all six skills along with the CLI binary. The binary upgrade is idempotent, so this works even if only the skills changed.

​
Using a setup skill

Open your agent inside the repo you want to wire up, then invoke the slash command:
Each skill probes the repo’s existing state — secrets, labels, VMs, webhooks — confirms a one-line plan with you, and only then makes changes. Skills are safe to re-run: state that already exists is detected and skipped rather than overwritten.

​
What boxd-setup-preview produces

After the skill runs, commenting on a PR or issue forks the golden and posts a live *.boxd.sh URL:
The fork syncs only what changed: source-only edits hot-reload (no rebuild), dependency/schema changes rebuild, compose/env changes recreate — picked from the diff against what the golden last served. The commands for each tier live in one config file (/etc/boxd-platform.conf) the skill fills in by detecting your stack; nothing is committed to your repo.

​
What boxd-setup-fix produces

boxd-setup-fix layers on top of the preview platform — run /boxd-setup-preview first. It adds the agent loop, triggered three ways:
Live updates land on the issue/PR as a comment that updates while the agent works (📖 reading LoginPage.vue → ✏️ editing → 🌐 loading the preview → 📸 capturing the screenshot). The PR opens with a before/after visual diff and a clickable preview URL on *.boxd.sh. Required pieces the skill walks you through: The PR is opened (or commits are pushed) by your user account using a gh token persisted on the golden during /boxd-setup-golden — no GitHub-Actions org-level “Allow Actions to create PRs” toggle needed.

​
What boxd-setup-deploy produces

Deploy is the sixth hook on the boxd-setup-preview listener — so setup just makes the hook live and registers one push webhook. It installs no second service, picks no new port, and commits nothing to your repo. On every push to the default branch:
deploy.sh is the same engine the preview forks use — it diffs what changed against what the golden last deployed and picks the cheapest correct action: hot-reload (source-only), rebuild (deps/schema), or recreate (compose/.env). The commands for each tier are the ones you gave /boxd-setup-preview (they live in /etc/boxd-platform.conf on the golden) — there’s no separate deploy config. The HMAC secret stays on the golden and in GitHub’s webhook config; nothing is added to your repo.

​
What boxd-setup-hermes produces

boxd-setup-hermes is the odd one out — instead of wiring boxd into a repo, it installs a third-party agent on a VM. Hermes (Nous Research) is a self-improving CLI agent with a built-in messaging gateway (Telegram/Discord/Slack/WhatsApp/Signal). The skill runs Hermes’ official installer on the box — Python, Node, ripgrep, ffmpeg, Playwright Chromium, and a hermes wrapper on PATH — then hands the interactive parts back to you:
The laptop version creates or reuses a VM and installs Hermes over boxd machine exec, then gives you the ssh <vm>.boxd command for the interactive hermes setup + hermes. The in-VM version installs Hermes right on the box you’re already on. Either way the skill stops at the interactive handoff — it never configures a provider or stores an API key for you.
Hermes is an independent project by Nous Research, not part of boxd. The skill just automates installing it on a boxd VM; optionally it can expose Hermes’ always-on messaging gateway on the machine’s public URL.

​
Manual install (if you prefer)

If you don’t want to run the CLI installer, fetch just the skills:
Restart Claude Code (or run /skills to refresh) and the six skills appear with autocomplete on /boxd-setup-….

​
Inside a VM

The setup skills above run on your laptop and drive a remote golden over the API. The same workflows also ship baked into every boxd VM image, for an agent working inside a VM (e.g. Claude Code on a boxd VM). They appear automatically at ~/.claude/skills/ — no install — and come in two kinds:
  • the in-VM counterparts of boxd-setup-{golden,preview,deploy,fix} (covered below),
  • boxd-setup-hermes, which installs the Hermes agent right on the box (no pre-baked platform needed — it just runs Hermes’ official installer), and
  • an everyday boxd skill — the in-VM counterpart of the laptop’s boxd-cli skill — that teaches the agent to drive the in-VM CLI (fork this VM, manage proxies, run commands in sibling VMs). It loads automatically whenever the agent works with boxd.
They’re much leaner, because inside the VM the agent already has root and the platform is preconfigured:
  • The current VM is the golden. boxd-setup-golden just installs and runs your app right there — no boxd new, no boxd machine exec.
  • The preview/fix/deploy platform is pre-baked at /opt/boxd-platform (the webhook(8) binary and systemd units ship dormant in the image). So boxd-setup-preview / -deploy / -fix skip all the staging, fetching, and installing — they fill in your repo’s config, run one local command, and register the GitHub webhooks.
The runtime is identical to the laptop skills (same listener, same deploy.sh, same hooks.<vm>.boxd.sh webhooks) — only the setup path differs (local, as the boxd user, vs. over the API). New platform versions reach in-VM agents on the next image release.
Today the in-VM skills cover golden, preview, deploy, fix, and hermes. They target Claude Code (the agent pre-installed on every VM).