Use Deploy to Vercel by Vercel Labs to guide an agent through publishing a project to Vercel. Check repository linkage, account access, and the intended team, choose a deployment path that fits the project, and create a preview for review before requesting a production release.
Describe the branch and project you want reviewed before any deployment proceeds. The prepared task can verify Vercel links and team scope, then propose a preview and its page checks within the authorization you actually provide.
Identify the branch, Vercel project and team, and the checks required before publishing.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatPreview and copy the request. It is not sent automatically from this page.
Reference: Deploy to Vercel https://github.com/vercel-labs/agent-skills/blob/main/skills/deploy-to-vercel/SKILL.md Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Create a Vercel preview for this branch, confirm the linked project and team first, and do not push or deploy production without asking me. Expected deliverable: A confirmed preview plan and verification checklist; deployment proceeds only within the scope you authorize.
Deploy to Vercel is a Vercel Labs Skill that guides an agent through selecting and carrying out a deployment workflow. It starts by checking the Git remote, local Vercel project linkage, CLI authentication, and available teams. Those checks establish the intended destination before the agent chooses a linked Git or another supported deployment route. The source defaults to preview deployments unless production is explicitly requested and requires approval before pushing code through its Git path. Installing the Skill supplies workflow instructions; a deployable project and the required account access are still needed. After deployment, verify the returned URL and project rather than treating an upload as proof of the intended result.
Preview builds and explicitly requested production releases both need a confirmed project and team. Deploy to Vercel distinguishes those scopes before execution, with local links, authorization, and the returned destination checked against the intended release.
A review build needs a known branch, linked project, and authorized preview scope. Request a preview rather than targeting production, then open it to check pages, assets, and key interactions. Share the resulting accessible URL only after verifying that it represents the intended change.
A local folder may carry Vercel links that point somewhere unexpected. Compare existing link files and Git remotes with the intended project identity before running a command that could connect or deploy it. If the identity remains ambiguous, record the mismatch and propose a correction instead of guessing the target.
An account with several Vercel teams needs an explicit deployment context. Confirm the intended team or use the linked project's organization ID, then verify the target project within that scope. Keep deployment records tied to the confirmed organization so account availability does not become permission to use an arbitrary team.
A production deployment requires an explicit request rather than an assumption based on a successful preview. Confirm the intended branch, project, team, and release scope before selecting the documented route, including approval for a Git push where that path requires it. Verify the returned production destination and relevant pages afterward, keeping deployment evidence separate from permission to publish.
A preview deployment needs a confirmed local project and the intended Vercel scope. Check the branch, linked project, and team before execution, then open the resulting URL to inspect pages and assets within the authorized preview task.
Ask the agent to read the Git remote, local Vercel link, authentication, and team context. Confirm the intended project and environment.
Use the method that matches the linked repository and available access. Review any proposed Git push before authorizing it.
Open the returned URL and inspect representative pages. Confirm the project, version, and preview or production destination.
Read another Skill guide and check its original source before using it.
