all-deploy

name

all-deploy

description

Deploys any web app, API, or agent to the internet with a strict pre-deploy audit and a preview → health-check → prod flow. Detects Next, Vite, Astro, Remix, Nuxt, SvelteKit, FastAPI, Flask, Express, MCP server, Claude Agent SDK script, Python worker, Dockerized, and static projects; routes to Vercel, Railway, Docker+SSH VPS, or cloudflared tunnel. Also supports a first-class "run locally" mode. At the start of each cloud deploy the skill asks the user whether to run full-auto (audit → preview → prod in one sequence) or step-by-step (confirm each phase); the user can skip that question by saying "auto" or "step by step" up front. Use when the user says "/all-deploy", "/deploy", "/despliega", "deploy this", "ship this", "push to prod", "get this online", "deploy my agent", "deploy my FastAPI", "run it locally", "corre esto localmente", "deploy auto", "deploy step by step", "paso a paso", "how do I put this on the internet", or otherwise asks to publish a project to a URL or run it locally.

all-deploy

Detects, audits, and deploys projects to the right host with a confirmed preview → prod flow. The unique value is detect → audit → route to the right CLI, not wrapping the CLI.

Configuration (edit these lines to change default behavior)

CONFIRMATION_MODE: ask_at_start
  # ask_at_start (default): the skill asks at the start of each cloud deploy
  #                         whether to run full-auto or step-by-step.
  # full_auto:              skip the question. Audit → preview → prod with a
  #                         5-second ESC window before prod.
  # always_ask:             skip the question. Require explicit "yes" before prod.
VISUAL_VERIFY: false           # true → screenshot preview via chrome-bridge-automation (frontend only)
ALLOW_DIRTY_TREE: false        # true → skip the "HEAD is clean" audit check

The default ask_at_start works for both solo authors and community users — the mode choice moves to runtime. Pinning to full_auto or always_ask is only useful when wrapping the skill in automation that can't answer the question interactively.

Hard Rules (never violate — these are the safety contract)

1. Never bypass or soften the audit. The audit is the only gate between the user's intent and live infra in full_auto mode. If a check cannot run, that itself is a block, not a reason to skip.
2. Never deploy to prod before a successful preview with a 2xx/3xx health check. Preview → summary → prod. No prod without a green preview in the same session.
3. Never commit, print, or log secrets. If a secret is found in tracked files, halt and guide removal + history rewrite as a separate user-approved step. Secret values never appear in summaries, logs, or commit messages.
4. Never auto-install or auto-authenticate third-party CLIs. Hand the user the command with the ! prefix (e.g., ! vercel login, ! railway login).
5. Never wrap a target CLI in a custom script that hides flags. Reference files document real commands the user can read and verify.
6. Never modify code to make audit pass without showing the diff first. .gitignore, .env.example, Dockerfile scaffolding, port-binding fixes — all shown and approved before applying.
7. Never deploy from a dirty working tree unless ALLOW_DIRTY_TREE: true is set. Uncommitted changes complicate rollback.
8. Respect "wait." Between preview and prod, any user utterance resembling hesitation (wait/hold/stop/not yet/abort) aborts the prod step cleanly.

Two Modes

Decide up front from the user's phrasing:

• Cloud deploy (default) — Phases 0 through 6 below. Triggers: "deploy", "ship", "push to prod", "get it online", "/all-deploy".
• Run locally — Phases 0, 1, 2, then a local-run step. Triggers: "run it locally", "corre esto localmente", "/all-deploy local", "just run it", or --local.

In run locally mode, run a scoped audit — only secrets-in-tracked-files, start-command-exists, and sane port binding. Skip: git-remote, clean HEAD, npm audit/pip-audit, .env.example completeness, and env-var delivery (no remote to deliver to). Then execute the detected start command (npm run dev / uvicorn main:app --reload --host 0.0.0.0 --port $PORT / docker compose up etc.) in the foreground, streaming output via Monitor. If the user asks to also expose the local server, chain into references/targets/cloudflared-tunnel.md. Everything else in this file concerns cloud deploy.

Cloud Deploy Workflow

Mode selection (runs before Phase 0 in ask_at_start mode)

Resolve the effective CONFIRMATION_MODE for this run:

1. If the user's invocation contains an explicit mode marker, adopt it and skip the question:

   • full_auto triggers: "auto", "full auto", "auto deploy", "deploy auto", "/all-deploy auto", "yolo".
   • always_ask triggers: "step", "step by step", "one at a time", "confirm each step", "paso a paso", "/all-deploy step".

2. Else if CONFIRMATION_MODE is pinned to full_auto or always_ask in the config block above, use that and skip the question.

3. Otherwise (ask_at_start, default), ask the user once, before Phase 0 runs:

   "Before we start — how should I run the deploy?

   1. Full auto — I run audit → preview → prod promotion in sequence. Prod fires after a 5-second ESC window. 2. Step by step — I stop for your OK between audit, preview, and prod.

   Reply 'auto' or 'step'."

The chosen mode scopes to this run only — a future invocation asks again (unless the user explicitly opts in via trigger phrase or the config block is pinned).

"Wait" / "stop" / "hold" at any point still aborts the prod step in both modes (Hard Rule 8). The difference is whether you get a 5-second ESC window (full_auto) or an explicit "yes"-required pause (always_ask) before the prod command runs.

Phase 0 — Prerequisites (target-independent)

Check in order. Each failure halts with a ! command for the user.

1. Git repo. Run git rev-parse --is-inside-work-tree. If not a repo, halt unless mode is run locally (which doesn't require git).
2. Git remote (cloud deploy only). Run git remote -v. If no remote is configured, halt unless the target will be docker-vps (deployable without a remote). This second clause is re-evaluated after Phase 3.
3. Language boundary. v1 fingerprints Node and Python. If the primary language is Go, Rust, Ruby, Elixir, Bun, or Deno, exit with: "v1 detects Node/Python ecosystems only. Run the target CLI directly (vercel, railway, flyctl, docker). Support for this language is planned in v2."

Target-CLI authentication is checked in Phase 3.5 (below), after the target is chosen.

Phase 0.5 — Permission-prompt seeding (first run only)

Tell the user: "Run the fewer-permission-prompts skill once on this project to seed .claude/settings.json with a deploy allowlist — otherwise every step will prompt." Pointer only. Never edit the user's settings here.

Phase 1 — Detect

Read references/project-types.md (skill-relative path — Claude resolves it against the installed skill directory) for the full fingerprint table. Inspect:

• Package managers & manifests: package.json, pnpm-lock.yaml, yarn.lock, package-lock.json, bun.lockb, pyproject.toml, requirements.txt, poetry.lock, uv.lock, Pipfile.
• Framework signals: next.config.*, vite.config.*, astro.config.*, remix.config.*, nuxt.config.*, svelte.config.*, app/ vs pages/, main.py with FastAPI(), Flask(), app = FastAPI(), server.py, index.html at root.
• Runtime version: .nvmrc, .node-version, engines in package.json, .python-version, python_version in pyproject.toml. If a long-running target is chosen and no runtime is pinned, audit blocks.
• DB / stateful deps: imports of sqlalchemy, psycopg, prisma, mongoose, redis, ioredis, sqlmodel. If found, surface "this service needs a database — provision one before prod" with the Railway add-on command from the Railway reference.
• Port + start command: uvicorn, gunicorn, next start, node server.js, python -m .... Check for 0.0.0.0 binding and $PORT usage. Localhost-only binding blocks for long-running targets.
• Monorepo: pnpm-workspace.yaml, turbo.json, nx.json, lerna.json, or "workspaces" in root package.json → enumerate packages and ask which one to deploy. Do not guess.
• Library / CLI (not a web deploy): Node signal — bin: field present in package.json OR (files: array present AND no scripts.start AND no HTTP framework imports like express, fastify, hono, next, koa). Python signal — [project.scripts] / console_scripts in pyproject.toml AND no uvicorn/gunicorn/flask/fastapi in declared scripts or imports. Do not use main: alone as a library signal — almost every Node web app also sets main:. Exit cleanly: "This looks like a package — /all-deploy targets web services, not npm/PyPI publishes."
• Existing deploy config: vercel.json, railway.toml, fly.toml, Dockerfile, render.yaml — respect, audit, do not regenerate without explicit ask.
• Existing project linkage: .vercel/project.json → reuse that Vercel project ID. railway.toml with project field → reuse. Re-deploy is the common case; fresh projects require an explicit "start fresh."

Output: a classification block and a ranked list of candidate targets with one-line rationale each. See references/project-types.md for the full target-ranking rubric.

Phase 2 — Audit (strict, blocking)

Run the audit script bundled with this skill (scripts/audit.py) against the current project directory. Claude resolves the skill path at load time — the invocation looks like:

python3 <SKILL_DIR>/scripts/audit.py <project-path>

Where <SKILL_DIR> is wherever the skill is installed (typically ~/.claude/skills/all-deploy/) and <project-path> is usually .. The script checks every item in references/audit-checklist.md: secrets in tracked files, .gitignore coverage, lockfile sanity, .env.example completeness (via scripts/env_extract.py), build/start script existence, port binding, clean HEAD, git-remote match, npm audit --production --audit-level=high or pip-audit.

Any failure halts. For each issue, show the fix as a diff (if applicable) and wait for the user's OK before applying. Auto-mode does not bypass audit.

Git-history secret scan is user-run, not automatic. In the audit output, surface: trufflehog git file://. or git log -p -S 'sk_' -S 'AKIA' -S 'ghp_' as a separate step. The skill never rewrites git history.

Phase 3 — Target selection

Present the ranked candidates from Phase 1 with one-line rationales. User picks or accepts the top pick with "ok". Only now load the target reference:

• references/targets/vercel.md — Next, Vite, Astro, Remix, Nuxt, SvelteKit, static
• references/targets/railway.md — FastAPI, Flask, Express, Python workers, MCP HTTP, Claude Agent SDK
• references/targets/docker-vps.md — any Dockerfile, stateful workloads, self-hosted
• references/targets/cloudflared-tunnel.md — expose local dev, quick demo

For agent-shaped projects, also load references/agents.md for per-agent-type adjustments (FastAPI/Flask HTTP, MCP stdio vs HTTP, Claude Agent SDK script, generic Python worker).

Phase 3.5 — Target CLI installed + authenticated

With the target chosen, verify its CLI is installed and authenticated. Do not auto-install or auto-login — hand the user the command with a ! prefix.

• Vercel: vercel whoami (install: npm i -g vercel; login: ! vercel login).
• Railway: railway whoami (install: npm i -g @railway/cli or brew install railway; login: ! railway login).
• Docker + SSH: ssh -o BatchMode=yes <host> true (requires pre-configured SSH key); docker --version locally.
• cloudflared: cloudflared tunnel list (install: brew install cloudflared; login: ! cloudflared tunnel login).

If the check fails, stop and surface the install/login command. Resume from Phase 3.5 after the user reports done.

Phase 4 — Execute (preview first, always) + env-var delivery

Follow the target reference's preview playbook. First pass is always preview/staging — never --prod on this phase.

Long-running command handling. Deploy commands take 3–10 min; the default 2-min Bash timeout will kill them.

• Default: run the deploy command via the Bash tool with run_in_background: true. You'll receive a completion notification when the CLI exits; Read the Bash output file at that point to parse the URL and detect errors. Do not chain sleep loops.
• When you need an early line (e.g., Railway prints the preview URL mid-run, cloudflared prints the tunnel URL before settling): use the Monitor tool against the same output file with a regex that matches the URL pattern plus known error signatures (Traceback, FAILED, error:). Monitor emits each match as a notification; the first URL match is what Phase 4.5 probes.

Env-var delivery (before preview runs). Source of truth is the user's local .env (never committed). Push required keys to the target:

• Vercel: vercel env add <KEY> preview then vercel env add <KEY> production (paste the value, or pipe it in — echo -n "$value" | vercel env add <KEY> <env>). Verify with vercel env ls.
• Railway: railway variables --set "KEY=value" — one call per key. There's no bulk-import flag; loop in shell over your local .env (see references/targets/railway.md).
• Docker+SSH: scp .env.production user@host:/app/.env or the environment: block in docker-compose.yml.
• cloudflared: inherits local environment; no remote vars needed.

Never print values. Confirm keys only.

Phase 4.5 — Preview health check (BLOCKING)

Capture the preview URL from the deploy CLI's stdout. Each target reference documents the exact parsing step; examples:

• Vercel: the preview URL is printed on the last non-empty stdout line, formatted like https://<project>-<hash>-<scope>.vercel.app.
• Railway: look for Deployment live at <url> in the railway up output.
• Docker+SSH: the URL is the user-configured http://<host>[:port] — the skill must ask or derive from docker-compose.yml port mappings.
• cloudflared: the URL is printed as https://<random>.trycloudflare.com or the configured hostname.

Assign the captured URL to $PREVIEW_URL, then probe:

curl -sSL -o /dev/null -w "%{http_code}" "$PREVIEW_URL"

(No -f — that would suppress the %{http_code} output on HTTP errors. -sSL keeps curl silent on success but still surfaces transport errors and follows redirects.)

A 2xx or 3xx status promotes to Phase 5. 4xx/5xx, empty output (connection refused, DNS failure), or a curl non-zero exit → stop. Report the failing endpoint with the target's log command (vercel logs, railway logs, ssh ... 'docker compose logs'). Do not promote.

Optional visual verify. If VISUAL_VERIFY: true and the project is a frontend, use chrome-bridge-automation to screenshot the preview and confirm the page renders (not blank, not error page). Curl 2xx/3xx is still the gate; screenshot is a bonus.

Phase 5 — Prod promotion

In full_auto mode, after audit + preview health both pass:

1. Print a one-screen summary block: target URL, exact command about to run, DNS impact if any, cost implication. For pricing, prefer a live deep-research lookup of current Vercel/Railway pricing. If unavailable, link the provider's pricing page. Do not hardcode plan prices in this file.
2. Print: "Prod promotion in 5 seconds — press ESC to interrupt." Then issue a real sleep 5 via the Bash tool as its own call. This is not theater — ESC during that sleep actually stops the turn. If the user does interrupt, do not issue the prod command on resume; ask what they want to do instead.
3. After the sleep returns cleanly, issue the prod command as a separate Bash call with run_in_background: true. Wait for the completion notification, then Read the Bash output file to extract the production URL. Use Monitor on the same output file only if you need to parse the URL before the CLI exits (Railway, cloudflared).

In always_ask mode, skip steps 2–3 and require an explicit "yes" in-turn before running the prod command. No sleep.

Respect interruption after preview. If between preview and prod the user types anything resembling hesitation (wait/hold/stop/not yet/abort), do not proceed to prod — treat the preview as the last green state and wait for explicit direction.

Phase 6 — Post-deploy verify + rollback surfacing

• Curl the production URL; confirm status.
• Confirm env vars are set on the remote (vercel env ls, railway variables, ssh ... 'docker compose config').
• Print the rollback path for this target (the user copies if needed later):
  • Vercel: vercel rollback (interactive picker) or vercel rollback <previous-deployment-url> — verify current CLI syntax.
  • Railway: no first-class rollback command. Redeploy a prior commit: git checkout <prev-sha> && railway up && git checkout -, or use the dashboard's Deployments → "Redeploy" on a prior build.
  • Docker+SSH: ssh <host> 'docker compose up -d --no-deps <service>' after re-tagging the prior image, or re-rsync a prior SHA and rebuild. See references/targets/docker-vps.md for both flows.
• Print the log-tail command: vercel logs <url> --follow, railway logs --follow, ssh <host> 'cd /app && docker compose logs -f'.

Target Selection — ranking rubric (quick reference)

Project signals	Top candidate	Why
next.config.*, vite.config.*, astro.config.*, SPA, SSG	Vercel	Zero-config, preview URLs, edge network
FastAPI / Flask / Express with long-running server	Railway	Simple, fast deploy, DB add-ons available
Any Dockerfile present, DB/volumes needed, self-host preference	Docker + SSH VPS	Full control, stateful-friendly
Local dev running, wants a quick public URL	cloudflared tunnel	No host needed, instant
MCP server	Railway (HTTP mode) or Docker+SSH	See references/agents.md
Claude Agent SDK script	Railway (worker mode) or cron	See references/agents.md

If signals conflict, present the top two with rationale and let the user pick.

Bundled Resources

• scripts/audit.py — deterministic pre-deploy audit. Invoked in Phase 2.
• scripts/env_extract.py — scans source for env-var usage, used by audit to verify .env.example completeness.
• references/project-types.md — full framework fingerprint table.
• references/audit-checklist.md — every audit rule explained with fix guidance.
• references/env-mapping.md — how env vars move between local .env and each target.
• references/agents.md — four agent shapes with per-type deploy adjustments.
• references/targets/*.md — one playbook per target, loaded only after Phase 3.
• assets/templates/ — Dockerfile.node, Dockerfile.python, docker-compose.example.yml, .env.example.template.

Platform Notes

• macOS + Linux only in v1. Windows community users should use WSL2 for path and shell compatibility.
• All commands assume bash/zsh. Paths use POSIX conventions.
• Network required for all cloud modes; run locally mode works offline.