# Golive > 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 t… - **Type:** Skill - **Install:** `agentstack add skill-mikehasa-golive-skill-golive` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [mikehasa](https://agentstack.voostack.com/s/mikehasa) - **Installs:** 0 - **Category:** [Databases](https://agentstack.voostack.com/c/databases) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [mikehasa](https://github.com/mikehasa) - **Source:** https://github.com/mikehasa/golive-skill/tree/main/skills/golive ## Install ```sh agentstack add skill-mikehasa-golive-skill-golive ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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. ```bash node /scripts/golive.mjs --json ``` `` 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--PLAN.md` and `docs/GOLIVE--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 **or production data**, 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. 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. 6. **Stay neutral.** Present provider options without steering. If they already use something, keep it. ## How the human connects accounts golive runs in *your* shell, so a token the human `export`s in their own terminal never reaches it. In order of preference: 1. **The vendor's browser login, when the adapter supports the required operations** (`vercel login`, `supabase login`, `resend login`). The human runs it in a **separate terminal window** (the Terminal app or their IDE's terminal), not with Claude Code's `!` prefix: `!` runs commands without a terminal (no TTY, stdin is `/dev/null`), so these interactive logins fail or hang there. A real user-controlled terminal can be opened for them when the host supports it; the human completes the login. Check the CLI is on PATH after install. A working CLI login does not prove golive's fallback implements every required operation. Nothing is copied. Never suggest a `--token` / `--key` login flag, even when a CLI's error hint does: it puts the secret on the command line (and, with `!`, into this chat). If macOS Keychain or the vendor login requests system authentication, explain which app is requesting access and why; the human responds to that system-controlled prompt. Never collect their Mac login password yourself or imitate an OS authorization prompt. 2. **Native token entry on macOS, when a manual API key is actually needed.** Give the exact variable name, provider token page, scope and permissions first. Explain that a GoLive input dialog will mask the value and the local process will save it without returning it to agent chat or command output. Then run `credentials --prompt NAME --lang en --json` (use `zh` when appropriate). Pass only the variable name, never its value. The human types or pastes directly into the native dialog. Do not inspect the dialog, clipboard, credential file or raw child output to retrieve it. This is local API-key entry, not a request for their Mac password. Storage remains the private plaintext credentials file, not Keychain. The dialog states the path and purpose. `saved` means local storage succeeded; rerun the provider check to validate access. If a named entry already exists, confirm it is the intended one to replace before using `--replace`. If `cleanupRequired` is true, treat a saved key as saved and repair only local cleanup; do not prompt for it again or retry replacement. See `references/troubleshooting.md` for the recovery. A cancellation means stop and wait; do not reopen the prompt or switch entry methods unasked. If `envOverride` is true, explain the existing process environment takes precedence; do not print its value or repeatedly replace the file entry. Use the manual fallback only when the platform/dialog is unavailable or the human prefers it, and explain the reason. Filesystem or concurrent-change failures need repair first; follow `references/troubleshooting.md`. 3. **Manual fallback: the credentials file** `~/.config/golive/credentials` (path shown by `doctor`). First run `credentials --setup --json` yourself: it creates a private empty file and missing directories, preserves existing contents, and returns metadata only. Never inspect those contents. Give the human the exact variable name, token page, resource scope and permissions for this stage before they open their own editor and add `NAME=value`. If suggesting nano, always spell out **Ctrl+O → Enter → Ctrl+X** (save, confirm filename, exit). The agent never enters token values. On Windows the setup command reports privacy as unknown; don't claim POSIX modes verify Windows ACLs. 4. The token exported in the shell the agent is launched from (then restart the agent). Vercel deploys always run through the Vercel CLI, so it must be installed (`npm i -g vercel`) either way; `VERCEL_TOKEN` only replaces `vercel login`. Use `doctor`'s `howToFix` to preserve the correct login, variable and permissions, but present only the applicable entry method in the human's language; do not recite editor setup when the native prompt is available. A login it shows as `! ` goes in a separate terminal window too. Supabase can reuse a supported CLI production-profile login for the complete Management API flow, including new projects and Auth settings: read `references/supabase.md` for the CLI version and OS credential-store limits. An explicit `SUPABASE_ACCESS_TOKEN` still takes precedence; a rejected explicit token never silently switches accounts through CLI fallback. Request a manual token only when needed by the supported credential path, and explain why. Do not make users do both login and token setup unnecessarily. Netlify can reuse `netlify login` for deployment and API env wiring; Neon can reuse `neon auth` through its CLI API transport. Read `references/netlify.md` / `references/neon.md` when selected. Do not require MCP installation: these adapters use vendor CLI/API paths. Netlify + Neon passed a supervised throwaway live run covering provisioning, env wiring, deployment and DB connectivity, plus separately approved schema/API/browser acceptance. This does not validate every framework, pairing or an Auth provider; explain the applicable limits when presenting the stack. ## Troubleshoot, then resume When a setup command fails, help resolve that specific failure before continuing. Keep the app directory, chosen stack, approved plan and completed resource IDs; onboarding does not restart. An install success is not proof that the user's terminal or the agent can find the executable. For `command not found`, installation/PATH/version differences, failed login or an interrupted provider operation, read `references/troubleshooting.md`. Use narrow diagnostics that cannot expose credentials, verify the repair with the appropriate CLI/account check, and return to the same deployment stage. Explain **what failed / what now passes / the next deployment step**. A repaired command does not authorize new destinations, paid operations or a changed plan. ## Flow ### 1. Detect: `detect --json` Tell the human the framework, the providers the code already uses, and the env var *names* it expects. Fix every **critical** finding in the code first (e.g. `secret-in-client-env`: a server secret in a browser-exposed name; `config-inlines-all-env`: the framework config inlines every env var into the browser). Until they are gone, golive won't write server secrets to that app's host. Read `notes` too (webhook events not found, a `define` golive couldn't resolve, …). ### 2. Choose providers: `menu --json`, then `init` Ask only about pieces the app **needs and doesn't have yet**. List what's already in the repo first and preserve those choices unless the human requests a change. Offer compatible providers, mark "automated" vs "guided", and include **Other — tell me the provider (guided, best effort)**. For example, an app already using Supabase can keep it while choosing Vercel, Netlify or another compatible host; this does not imply an existing Supabase cloud project or a tested cross-pairing. Explain relevant framework limitations before presenting a provider as compatible. If they say "you pick", suggest the option with the **fewest new accounts** and say why in one line. For Other, use the menu's provider id when listed, or a lowercase letters/digits/hyphens id for an unlisted provider (for example, `hosting=example-host`), never the placeholder `other`. An accepted id records the choice; it does not add an adapter or guarantee deployment. Read `references/guided.md`: check current official documentation, prefer a suitable official CLI, consider an available official MCP or API when safe, then guide dashboard steps. No MCP install is required. Stop with a concrete blocker when no safe documented path is available. Ask whether they have a custom domain and which "from" address emails use. For DNS, distinguish the registrar (where the domain was bought) from the authoritative DNS host. Cloudflare, GoDaddy and Porkbun DNS are automated; a domain bought at one may use another's DNS. The GoDaddy/Porkbun adapters check public delegation and do not move nameservers or buy domains. Neon supplies server-side Postgres connections, not the Supabase SDK or Supabase Auth. Choosing it does not migrate an existing Supabase app. For an existing Neon database explicitly select its branch, database and role; show those selectors in the approval summary. New Free projects use the documented initial defaults. Schema migrations and app-level authorization need separate review. ``` init --stack hosting=,db=,auth=,payments=,email=,dns= [--domain example.com] [--email-from hello@example.com] [--project hosting=,db=] [--webhook-path /api/...] [--events a,b] [--stripe-publishable test=pk_test_…,live=pk_live_…] --json ``` - **Account and project are separate choices:** a Supabase dependency/env name in code proves only that the app needs Supabase, not that an account or database already exists. Ask whether this app has an existing project. If not, explain that Vercel hosts the app and Supabase hosts its database/Auth: two provider projects for one product. For a new user, guide browser signup and a Free organization first; golive can create the database project after approval. Don't ask them to choose an unrelated project merely to finish a token form. If project-scoped access is their only option, explain the alternative: they create a Free project in the dashboard, then select that exact project for this app and for the scoped token. - **Existing projects:** pass `--project` for a deliberately chosen existing project. Otherwise golive may propose adopting a same-named project or creating one; neither implies consent. In a throwaway test, stop on a same-name collision and choose a fresh name instead of adopting it. - **Stripe webhook:** check `detect.webhooks[]`, both `path` and `events` (the event types the handler handles), against the handler code. Pass `--webhook-path` / `--events` if either is wrong or `events` is empty. ### 3. Accounts: `doctor --json` For each provider with `ok: false`, give the human its `howToFix` (see "How the human connects accounts"). `credentials` shows the credentials file's path, whether it's private, and the *names* in it. Re-run until everything is ok or the rest are guided. For a guided provider, `doctor` can return `ok: false` and exit code 2 because no adapter exists; this alone is not a login failure or a reason to request another credential. Verify its account through the chosen official tool or dashboard, following `references/guided.md`. For Supabase, distinguish token **capabilities** from **resource scope**: "Full access" to one project cannot create another project or manage its organization. A `/profile` 403 can mean a project-scoped token, not an invalid key. Explain the required scope; don't blindly ask for another Full access token. A passing account check doesn't prove every later endpoint permission. ### 4. Plan: `plan --json` Explain the steps by provider, in plain language, and call out: - which steps **write**, and which `needs` `--confirm-live` / `--confirm-dns` / `--confirm-destroy` - `project:hosting` / `project:db`: which project and account every write goes to. If a step **creates** a project, its preview lists … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [mikehasa](https://github.com/mikehasa) - **Source:** [mikehasa/golive-skill](https://github.com/mikehasa/golive-skill) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** yes - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-mikehasa-golive-skill-golive - Seller: https://agentstack.voostack.com/s/mikehasa - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.