Vercel's CLI now hands your agent the manual with the database

Vercel's CLI has changed what happens when you install a Marketplace integration from the terminal: it now also installs that provider's agent skills, pulled from skills.sh, into the project ^[1][8]. According to Neon, which wrote up its own arrival in that flow, one command can provision a database, wire it to a Vercel project, pull the credentials locally, and drop in the vendor's own instructions for using what it just created ^[3].

The mechanics are duller than the consequence. The relevant subcommand is `vercel integration`, which manages Marketplace integrations from the terminal and will install an integration first if the team does not already have it ^[2]. It is also exposed as `vercel install`, aliased to `vercel i`, so `vc i neon` reaches the same place [c2a]. Run plain, it prompts for the choices it needs, such as billing plan and region; run with flags, it skips the prompts entirely, which is the property that makes it usable by an agent ^[4]. In Neon's case the flagged invocation provisions a Neon database (Lakebase Postgres) from the Marketplace, connects it to the project and injects connection variables such as `DATABASE_URL`, pulls those variables locally via `vercel env pull`, and installs Neon's agent skills ^[3]. That is four operations behind one call with zero human decision points ^[5].

Two of those operations are ordinary plumbing. The fourth is a distribution channel. Whoever writes the skill file gets to define the agent's working model of the product at the exact moment the product appears in the repo, and Neon says the point is that the agent gets Neon's own guidance instead of reinventing workflows ^[9]. Neon also positions agents as the first-class interface for deploying Neon ^[11], and the skills can be installed on their own without provisioning anything ^[10]. Neon's post does not say how skill versions are pinned, or whether anything reviews the text before an agent starts following it ^[12].

The billing shape deserves attention precisely because a flagged command can be run unattended. `vercel integration add neon` installs the Vercel-Managed Integration, creates a Neon account if you do not have one, and bills through your Vercel invoice; keeping billing with Neon means choosing the Neon-Managed Integration instead ^[6]. That choice also changes cleanup: the Vercel-Managed path follows Vercel's deployment retention policy, while the Neon-Managed path can follow Git branch deletion ^[14]. With Preview enabled, every Vercel Preview Deployment gets its own isolated Neon branch, described by Neon as an instant copy with the same schema and data, ready in about a second, starting as a pointer to existing storage and copying only on divergence ^[13]. If Managed Better Auth is on the production branch, previews also receive `NEON_AUTH_BASE_URL` ^[15]. The rest of the surface is browsable from the terminal too: `discover`, `categories`, `guide neon`, and `open neon` ^[7].

What to watch: whether other Marketplace providers start shipping skills through the same hook, and how quickly the skills.sh payload becomes something teams want pinned and diffed rather than fetched fresh; whether agents driving `vercel integration add` end up selecting the Vercel-invoiced path by default simply because it is the one that needs no existing account ^[6]; and how preview-branch cleanup behaves in repositories that open dozens of short-lived environments, given that the two integration paths expire them on different triggers ^[14].