Release

release - deployment readiness for Render and Vercel

Context reuse: Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.

First action: Before project inspection, preflight, or any other tool call, publish running to blueprint/.state/run.json using the dashboard activity contract in AGENTS.md.

Where this sits in the workflow:

/complete  ->  [release]  ->  deploy with explicit approval
(feature       (config,       (human confirms
 finished)      checks)        external action)

/release is an optional deployment prep step. It gets the app ready to ship, but it is not a deploy button. It can inspect, recommend, create local config files, and run local checks. It must stop before any external provider action unless the user gives an explicit yes in the current chat.

Initial targets:

• Render - static sites, web services, background workers, cron jobs, and render.yaml when useful.
• Vercel - frontend apps, full-stack framework apps, serverless functions, and vercel.json when useful.

Input

Optional scope:

• no argument: inspect the project and recommend Render or Vercel if the target is obvious; otherwise ask which target to prepare
• render: prepare Render readiness and config
• vercel: prepare Vercel readiness and config
• check: read-only deployment readiness report
• config: focus on creating or updating local provider config files

If the user asks to deploy, connect a provider, create a remote service, set remote env vars, push, publish, or run provider commands that affect a remote, pause and ask for explicit confirmation before doing it.

Step 1 - read the project

Read:

• AGENTS.md
• blueprint/project-plan.md
• blueprint/build-plan.md
• blueprint/context/project-overview.md
• blueprint/context/current-feature.md
• package or build files such as package.json, lockfiles, framework config, Dockerfile, render.yaml, vercel.json, .env.example, and README files
• git branch and working tree status

Identify:

• app type: static frontend, SSR app, API service, worker, CLI, monorepo, or hybrid
• build command, start command, dev command, test command, output directory, and package manager
• runtime needs: Node version, Python version, Docker, database, cache, object storage, queues, background jobs, cron, migrations, or file uploads
• env vars by name only; never print or write secret values
• health path or smoke test path

Step 2 - choose the provider shape

For Render, decide whether the app should be:

• static site
• web service
• background worker
• cron job
• database paired with a service

For Vercel, decide whether the app should be:

• framework deployment with auto-detected settings
• static output deployment
• serverless or edge function app
• monorepo project with a root directory

If the provider is a poor fit, say that plainly and recommend the better target. Examples: long-running workers usually fit Render better; a mostly frontend Next.js or Astro site usually fits Vercel well.

Step 3 - verify local readiness

Run only local, non-destructive checks that match AGENTS.md:

• install check only if dependencies are already present or the user approves an install
• build command
• test command when declared
• preview or start command if safe, then smoke test the health path
• lint or typecheck only when listed in project commands or package scripts

If a command is missing, report the gap instead of inventing certainty. If a command needs secrets, list the env var names needed and skip that check.