Agent deploy skill

The Appaloft Deploy Skill is the deploy subprotocol inside the full Appaloft Skill. It is not a new deployment operation and not a replacement for MCP; it is a user-layer protocol that tells an AI agent how to deploy through the existing CLI, HTTP API, Web Quick Deploy, or MCP tools surfaces.

The skill covers the full Appaloft deploy entry surface and keeps the result focused on what the user needs next: access URL, deployment status, logs, diagnostics, and recovery. Static output is one fast entrypoint, not the boundary of the skill. For GitHub Actions, the agent must first distinguish Pure SSH Action, Self-hosted Server Action, and Product-grade Preview instead of collapsing them into one template.

Install the full Appaloft skill:

npx skills add appaloft/appaloft

The installer only copies the full Appaloft skill. It does not deploy an app, create resources, call deployment APIs, or wrap appaloft deploy. The deploy protocol is part of the full skill, not a separate npm installer.

1. Inspect the source safely: read only project structure, build scripts, runtime ports, image references, Docker/Compose files, static output directories, and Appaloft config.
2. Choose the smallest entrypoint: Appaloft config first; then select prebuilt image, Compose, Dockerfile, built static output, static source, or workspace commands from the evidence.
3. Use existing operations: create or choose the project, server, environment, and resource, then request deployments.create.
4. Return the outcome: access URL first, then deployment id, resource id, logs command, diagnostic command, and recovery readiness command.

• Pure SSH Action: default control-plane-mode: none; the Action installs/runs the CLI, deploys over SSH, and uses server-owned ssh-pglite state on the SSH target. Do not require an Appaloft console, deploy token, project id, resource id, or server id.
• Self-hosted Server Action: an existing self-hosted Appaloft console/API owns state. The Action calls the server API selected by control-plane-url, must use appaloft-token, and does not run the CLI or open SSH. Prefer server-config-deploy: true so the server reads appaloft.yml, applies profile/env/domain intent, then dispatches ids-only deployment admission.
• Product-grade Preview: Appaloft Cloud or a self-hosted control plane owns preview policy, GitHub App webhooks, comments/checks, cleanup retry, scheduler, audit, and quota. It is not the same as an Action-only PR preview workflow file maintained by the repository.

When source-link or repository binding context is missing, prompt the user to establish the binding or run one trusted bootstrap context. Project/resource/server ids are for first bootstrap, advanced override, or debugging, not the default input an ordinary user should provide.

• Do not read .env, private keys, token files, or cloud credential files.
• Do not put secret values in logs, pull requests, diagnostic summaries, or chat replies.
• Do not bypass Appaloft by mutating Docker, SSH, databases, or provider SDKs directly.
• Do not put source, runtime, or network fields into deployments.create; they belong to the Resource profile and deployment snapshot.
• Do not assume Appaloft uploads artifacts to a hosted cloud. By default, deployment still targets the user's selected BYOS destination.

Return a compact outcome:

• access URL, or why it is not available yet;
• deployment id and resource id;
• current lifecycle status;
• appaloft logs <deploymentId>;
• appaloft resource diagnose <resourceId>;
• appaloft deployments recovery-readiness <deploymentId>.

If the deployment fails, read structured errors, logs, diagnostics, and recovery readiness before suggesting the next action.

The complete governing source lives in docs/agent/appaloft-deploy-skill.md. The installable full skill lives at skills/appaloft; its deploy protocol lives at skills/appaloft/references/deploy-protocol.md.