Use Vercel Optimize by Vercel Labs to investigate cost and performance in a deployed Vercel project. Start with usage and production signals, identify routes or settings supported by evidence, and review prioritized recommendations tied to the project’s framework, source files, and available observability access.
Bring a usage increase, slow route, or cache question with the measurements behind it. Ask for an evidence-based investigation connecting metrics to source and settings, with optimization choices that can be retested and still satisfy content-freshness requirements.
Include the period, affected functions or routes, and available cost or latency data.
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: Vercel Optimize https://github.com/vercel-labs/agent-skills/blob/main/skills/vercel-optimize/SKILL.md Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Investigate last month's Vercel function-cost increase. Confirm the project scope, use available metrics, and rank only evidence-backed opportunities. Expected deliverable: Evidence-backed opportunities ranked by likely impact, with a measurement plan for each.
Vercel Optimize is a Vercel Labs Skill for investigating deployed-project cost and performance using production evidence. Its bundled scripts collect signals and select candidates before the agent reads the related source files. This keeps recommendations tied to observed routes and settings rather than a broad search for suspicious code. The source describes framework-specific support for Next.js, SvelteKit, Nuxt, and limited Astro use. It requires a linked project, suitable CLI and Node versions, and the intended account scope; route-level metric-backed advice also needs Observability Plus. The workflow produces ranked recommendations, whose effects should be checked against the same workload after any implementation.
Usage increases, costly routes, and cache proposals need measured evidence before an optimization choice. Compare how Vercel Optimize links billing periods and route signals to source changes while retaining content-freshness and invalidation requirements.
An unexpected rise in function usage needs a comparable billing period and route-level metrics before attributing cost to one endpoint or cache setting. Connect the observed usage to its source and rank optimization candidates by evidence. The explanation should distinguish measured contributors from plausible but untested causes.
A page that seems slow or expensive should be investigated through its route signals, performance traces, and deployment versions. Let those measurements identify relevant source files and settings, then make a change that can be measured again. Preserve the path from metric to code so the optimization has a checkable basis.
A cache proposal must account for current hit patterns, framework behavior, and the content's freshness requirements. Compare ISR, middleware, or response-cache changes only after those conditions are understood. Explain invalidation risks and recheck both cache hits and content updates so lower usage does not hide stale results.
Before accepting a proposed optimization, agree on the route, time window, workload, and freshness conditions that will be compared. Retain the current measurements and link them to the relevant deployment. The later review can then judge whether cost or latency changed under comparable conditions, rather than attributing every movement in the dashboard to the most recent code edit.
Optimization begins with the measured usage or route behavior that needs an explanation. Follow the evidence into relevant source and settings, compare proposed changes with freshness constraints, and repeat the measurements before accepting a cost or latency improvement.
Confirm the linked Vercel project, account, and framework. Check the source’s CLI, Node, and observability requirements before collecting signals.
Use the bundled collection workflow to gather production signals. Let its gate identify candidates before investigating source files.
Inspect only the selected routes or settings with the agent. Review evidence, framework-version fit, and a validation plan for each proposed change.
Read another Skill guide and check its original source before using it.
