Building with an AI assistant

An AI assistant can take you from an idea to an app running on your device: write the app and its Dockerfile, push it to a repository, build it on the Hub, and put it on your device as a new revision. It can also build flashable images for new devices. You stay in charge of the decisions — which device, which access, which secrets — and the assistant asks before anything that changes a device.

Two pieces make that work:

• The pantavisor-apps skill teaches the assistant how Pantavisor apps and Hub builds work: how to prepare a repository, which build options to choose, how signing, secrets and images fit together, how to deploy, and what a failed build means.
• A way to act on the Hub: the pvr CLI when the assistant can run commands, or the MCP connector when it can't.

Development preview. Builds run on the stage Hub. Point the assistant at stage: https://api.stage.pantahub.com/mcp for the connector, and pvr logged into https://api.stage.pantahub.com.

Install the skill

The skill follows the open Agent Skills format and is published at pantavisor/pantavisor-skills.

Claude Code, Codex, OpenCode, Antigravity and other coding agents:

npx skills add pantavisor/pantavisor-skills

It finds the agents installed on your machine and puts the skill where each one looks. For the Antigravity CLI (agy), or without Node, use the install script instead; it covers every agent above:

curl -fsSL https://raw.githubusercontent.com/pantavisor/pantavisor-skills/main/install.sh | sh

Agent	Where the skill goes
Claude Code	~/.claude/skills/
Codex, OpenCode	~/.agents/skills/
Antigravity CLI (agy), Gemini CLI	~/.gemini/skills/
Antigravity app	~/.gemini/antigravity/skills/

Add --project to the script to install into the current project only (.claude/skills/, .agents/skills/), and --uninstall to remove it.

claude.ai and the Claude apps: download pantavisor-apps.skill from the latest release and upload it in Settings → Capabilities → Skills.

Chats without skills: a client that supports MCP but not skills gets the same guidance from the connector itself — see Guidance for assistants.

Give it a way to reach the Hub

The skill picks its path by what the assistant can do:

• It can run commands and pvr is installed — the usual case in a coding agent. It builds and deploys with pvr, logged in as you, from your local checkout. Use a pvr whose pvr --help lists build, and sign in (Builds with pvr):

  pvr login https://api.stage.pantahub.com/auth/auth_status

• It can't run commands — the usual case in claude.ai. It uses the MCP connector. Add it to your client:

  Client	Add	Sign in
  claude.ai	Settings → Connectors → Add custom connector, https://api.stage.pantahub.com/mcp	Connect
  Claude Code	claude mcp add --transport http pantahub-stage https://api.stage.pantahub.com/mcp	/mcp
  Codex	codex mcp add pantahub-stage --url https://api.stage.pantahub.com/mcp	codex mcp login pantahub-stage
  OpenCode	opencode mcp add --global --url https://api.stage.pantahub.com/mcp pantahub-stage	opencode mcp auth pantahub-stage
  Antigravity	agy mcp add pantahub-stage https://api.stage.pantahub.com/mcp	in the app, on first use

  Connecting asks you to approve everything the connector can do, on one screen (What you approve); your client still asks you before each call that changes something.

Having both is fine: the skill prefers pvr for building and uses either to deploy.

Before you ask

Have these ready; the assistant will ask for whatever is missing.

• A claimed device on the same Hub, and its nick or id.
• A Git repository the assistant can push to (or let it create one), on GitHub or GitLab. A private repository needs a Git secret in your account.
• For flashable images: a signing identity with a platform key and, for devices that join your account on first boot, a config secret holding a join token.

You create secrets yourself, in the web app or with pvr secret add. The assistant refers to them by name and never sees or asks for their values.

What to ask

Describe the outcome; you don't need to spell out the steps. For an app:

Build me a small app for my Pantavisor device and put it on it.

- Create a new GitHub repository in my account named pv-hello: a tiny
  HTTP server that answers "hello" on port 8080, built as a Pantavisor
  container for arm64.
- Build it on the Pantacor Hub stage and deploy it to my device cm5,
  keeping everything that already runs there.
- Ask me before anything that changes the device.

Tell me the repository URL, the build id, the revision you posted and how
you checked the app runs.

For a flashable image:

Make a flashable image for new CM5 devices that already contain that app.

- Hub stage, signing identity my-identity, policy green.
- New devices should join my account on first boot, with the join-token
  config secret I already have.
- Reuse what already exists in my account. Don't flash anything; give me
  the image build id, the artifact name and how to flash it.

Other good starting points: "my build <id> failed, why?", "my device rolled back after the last update, what happened?", "package this Yocto layer as a Pantavisor app".

What the assistant does

For an app, the skill walks the assistant through the same path as How builds work:

1. Prepare the repository — a Dockerfile, or a pvpkg.json for Yocto or Buildroot (Preparing a repository).
2. Build — with pvr build or start_build, for the device's architecture, and follow it to the end.
3. Deploy — merge the export into a new revision that keeps the device's other apps, show you the plan, and commit it only when you say so (Putting a build on a device).
4. Check — read the device's status and logs until the revision is DONE, and test the app where it can.

For an image, it reuses your image base and factory builds where they exist, then builds the final image per policy (Flashable device images). It never flashes a device.

Ground rules the skill enforces

• No secret values. Keys, tokens and passwords stay in the web app or pvr; the assistant handles names only.
• Ask before changing a device. Revisions and configuration changes are shown to you first; MCP clients also ask before every tool that changes something.
• One Hub per task. Devices, secrets and builds of production and stage don't see each other. The assistant uses the Hub you name, or the one pvr and the connector already point at.
• Access is approved by you. When the connector refuses a call for missing access, the assistant asks you to approve it in your client and doesn't look for a way around it.

When something goes wrong

What you see	What to do
The assistant doesn't seem to know about Pantavisor	The skill isn't installed where that agent looks; check the table in Install the skill, then restart the agent
npx skills add fails with ETARGET	npm hasn't caught up with a just-published version of the installer; retry in a few minutes, or use the install script
Builds answer 404 or "not enabled"	That Hub doesn't run builds; use stage
A call is refused for missing access	The connection was approved before it asked for everything; disconnect the connector and connect it again (in Codex, codex mcp login again)
A build failed	Ask the assistant to diagnose it; it reads the build's log, and explains the cause and the fix (Statuses)