Start with the site and the deploy target

Codex can build or update a website or app, run the project checks, deploy it with Vercel, and return the URL.

The useful handoff is concrete: a repo, screenshot, map, design brief, product note, API doc, or data source. Codex should inspect the project before changing it, then use the Vercel plugin to deploy a preview by default.

Use @build-web-apps when Codex needs to build or polish the app. Use @vercel when it should deploy, inspect the deployment, or read Vercel build logs.

Check the result before you share it

Codex should tell you what it changed, which command it used to build the project, and whether the Vercel deployment is ready. If the deploy needs an environment variable, team choice, domain setting, or login step, Codex should call that out instead of pretending the site is finished.

Keep production changes explicit. A preview deployment is the default; ask for production only when you mean it.

Iterate from the live URL

Once you have the preview, keep the same thread open. Ask Codex to open the URL, fix layout issues, update copy, wire missing data, or read Vercel logs if the deploy fails. The thread already has the repo, deployment, and build context.

Good follow-ups are specific:

• “The mobile layout is cramped. Fix it and redeploy the preview.”
• “Use the same project and add the latest data from [source].”
• “Read the failed build logs and fix the deploy.”