/golive

name: golive
description: Take an agent-written app from repo to live production on the user's OWN accounts, with providers they choose (hosting, database, auth, payments, email, domain/DNS). The human connects accounts and approves changes; supported wiring operations run through a local CLI and produce verification evidence with explicit limits. Use when the user wants to ship, deploy, go live, launch, publish, or put their app online, or asks to wire up env vars, webhooks, auth settings (signup, email confirmation, password policy), a real signup → confirmation email → login journey, password recovery, account isolation between two users, auth redirects, email DNS or a custom domain.
license: MIT

golive: ship this app to production, on the user's own accounts

Help the agent take an app live on accounts the human owns. The `golive` script handles supported provider operations after approval and records what its checks establish. The human connects accounts and handles purchases; app migrations, business flows and guided steps need their own review. Never turn an infrastructure check into a claim that the entire app works.

node <this-skill-dir>/scripts/golive.mjs <command> --json

`<this-skill-dir>` is the folder containing this SKILL.md. Every command prints one JSON document. Exit code `2` means "worked, but something needs attention": read the JSON.

Start with a verified release

At the start of a new deployment run, run `version --json` and `update-check --json` using the script above. The runtime verifies the complete instruction/reference/script bundle before accessing accounts. Update checking reads only public metadata, is cached and bounded, and an offline/unavailable result does not block the deployment flow. `GOLIVE_UPDATE_CHECK=0` disables it. Read `references/updates.md` for installation ownership, explicit updates, rollback and opt-in automatic replacement. Automatic replacement is off by default and only runs between deployment runs for copies owned by our installer. Skills CLI and plugin copies stay with their managers. Never update between a plan and its apply. A changed release requires a new plan and human approval.

Conversation and progress

• Follow the human's language: English for English, Chinese for Chinese, mixed when they mix.

These English instructions do not fix the language of the conversation.

• Keep the current stage visible at handoffs: **completed / next step / what you need from them**.

If they ask "what's next?", read the existing `golive.yaml`, non-secret `.golive/state.json`, and latest golive plan/result first. Resume the current stage; don't restart onboarding or treat a question as approval. Credentials, `.env`, and vendor login files are never context to read.

• Name agent-written deployment docs `docs/GOLIVE-<stage>-PLAN.md` and

`docs/GOLIVE-<stage>-RESULT.md`; link them in chat. The CLI's final report is `GOLIVE_REPORT.md`. Preserve older artifacts as evidence and say which current document supersedes them.

• Use bundled provider references for the normal flow. Check current official docs for changing

permissions, CLI versions, pricing, or an actual mismatch, and explain that purpose briefly. Reuse facts already verified in this session unless new evidence changes them. Don't describe ordinary onboarding as open-ended "researching the deployment plan" or claim no web lookup is needed.

Hard rules (never break these)

1. **Never print, echo, `cat`, or paste a secret value** (`.env` files, API keys, tokens, database URLs, `~/.config/golive/credentials`). Refer to secrets by name. The script never prints them. 2. **Secrets never go through this chat.** Never ask the human to paste a secret key or token here. Prefer provider integrations or supported local secret transport. When guided setup has no safe automated route, the human may enter a needed value directly in the destination dashboard using their own browser; the agent must not view or capture it. If they paste one into chat anyway, don't use it; tell them it is now in the transcript and should be rotated. The one exception: Stripe **publishable** keys (`pk_test_…`, `pk_live_…`) are public, so the human may give them in chat. Never `sk_`, `rk_` or `whsec_`. 3. **No provider/account writes until the human approves the plan.** Local credential setup and human-submitted credential entry, `init`, and report files can be prepared during onboarding. Explain `plan` and get a clear yes before `apply`. Pass `--confirm-live` (live payments, production data, or a **first** production deploy — the first write to a destination golive has never deployed; e.g. the `auth:test-user` account, the `auth:isolation` second account, `auth-signup`'s throwaway probe and the `auth:recovery` password rotation), `--confirm-dns` (DNS records) or `--confirm-destroy` (deletions) only if the human explicitly approved those categories. Say why you are asking each one: `steps[].needs` names the flags a step requires, and a first production deploy needs `--confirm-live` because approving the plan approves what that deploy contains, not the first write to production itself. Later deploys of that target need no extra flag. 4. **Never buy anything or create accounts for them.** Signups, payment methods, identity checks (KYC) and domain purchases are handoffs the human does in their browser. 5. **A handoff is closed only by a passing check**, not by anyone saying "done". `done: false` is open. `done: null` (a `manual` item, or its check skipped) cannot be verified by golive: confirm it with the human and name it as **not verified by golive** in your final summary. A skipped check's evidence names the recorded outcome of the step it verifies when state has one, so a `done: null` item never contradicts `.golive/state.json`: if the evidence says the step is recorded done, the work ran and only this invocation cou