deploylisted

Deploys to Vercel. Verifies /audit passed. Helps configure domain, DNS, and secret storage. Offers Google Cloud Secret Manager as the recommended store for sensitive API keys. Post-deploy smoke test.
dkadts/landing-kit-building · ★ 2 · Web & Frontend · score 73

Install: claude install-skill dkadts/landing-kit-building

# /deploy Final step. Publishes the landing to production. DOES NOT RUN if `/audit` did not pass. ## When to use - After `/audit` with pass verdict. - Updates to an already-deployed landing (then the gate is only audit). ## Requirements — HARD BLOCKING - `site/_audit-report.md` exists with verdict = OK. - No uncommitted changes in git (user commits themselves — CLAUDE.md rule 5). - `vercel.json` present. - All env vars from `brief/06-technical.md` are configured wherever the user chose to store them (Vercel Dashboard, or Google Cloud Secret Manager — see Step 3a). ## Process **Step 1. Verify readiness** - Read `site/_audit-report.md`, verdict must be OK. - Read `brief/06-technical.md` — domain, region, env vars. - Read `brief/blocks/contact-form.md` — which backend (affects env vars). **Step 2. First deploy vs update** If first deploy: - User installs Vercel CLI: `npm i -g vercel`. - Init: `vercel` (asks project, domain, etc.). - Configure secret storage (Step 3a). - Configure env vars (Step 3b). - Configure domain (Step 4): DNS at the registrar → Vercel. If update: - `vercel --prod` (or via GitHub integration, if wired). **Step 3a. Secret storage choice** **Ask the user how to store sensitive keys** before writing anything to Vercel. Options: **Option A. Vercel env vars only** (simplest, default) - Secrets live in Vercel Dashboard → Settings → Environment Variables. - Marked as "Sensitive" so they're write-only after creation. - Trade-off: rotation is manual, a