Automate the Audit

You spent two sections hand-tuning Saturday. You enabled Fluid Compute, wrapped a slow lookup in Runtime Cache, moved the drops page off a timer, tuned images, trimmed builds. You know every one of those levers now, where it lives and what it does.

But you don't have one project. You have the portfolio site. The side project three people use. The thing you shipped in 2024 and haven't opened since. The internal dashboard nobody remembers deploying.

You are never going to hand-audit all of those. Nobody is. That's the gap vercel-optimize fills. It's an open-source agent skill that finds the same things you just found on Saturday, except it starts from your production metrics and does the digging for you.

Here's the part that matters: the skill doesn't guess from your code. It pulls your route-level metrics first, runs deterministic checks with thresholds that live in code (no model decides what counts as "too slow"), and only investigates the routes that pass. Then it writes a report you can hand to a teammate. You learned the levers by hand so you can read that report and tell a good recommendation from a bad one. That's the whole point of doing Saturday first.

Outcome

You generate a vercel-optimize report for a real project and, for every recommendation it marks ready, you can name the lesson that taught the concept and decide whether to accept it.

Hands-on exercise 4.5

No code change to Saturday this time. You're running a tool and reading what it tells you.

Requirements:

1. Install the skill with npx skills add vercel-labs/agent-skills --skill vercel-optimize.
2. From Saturday's project directory, run /vercel-optimize. Because you already did the work in Sections 3 and 4, expect a mostly clean report. That clean report is the proof your manual audit held.
3. Now run it against a different project you own, ideally one you've never optimized. Let it pull real metrics.
4. Read the full Markdown report top to bottom.
5. For every recommendation under "ready," find the lesson in this course that taught the underlying concept.
6. For at least one recommendation, decide out loud whether you'd accept or reject it, and why.

Implementation hints:

• The skill treats your project configuration as ground truth. If you already enabled Fluid Compute, it will not tell you to enable it. If it does, the project link is wrong and it never read your real settings.
• Metrics come first. If the skill starts reading files before it has production signals, something is off. On a brand-new project with no traffic, there's nothing for it to measure yet.
• A finding filed under "needs more evidence" is not a failure. It means there's a real production signal but the safe code change isn't provable yet. That's more honest than a confident guess, and it's still worth a ticket.
• The report is built for handoff. The ranked recommendations, affected files, and before/after code are designed to drop into a PR or an issue.

Try It

Run it against Saturday first. Since the compute and bandwidth work is done, the response should be short and unexciting:

vercel-optimize — saturday

Investigated 6 routes across Functions, CDN Requests, and ISR.
Ready recommendations: 0
Needs more evidence: 1

Fluid Compute: already enabled (no action).
ISR writes on /drops: within expected range (on-demand revalidation detected).
Runtime cache on /api/stock-check: cache policy present.

Needs more evidence:
  /products/[slug] — image cache TTL could likely go longer, but follow-up
  metrics are too sparse to confirm. Revisit after more traffic.

That's a passing grade on the work you just did. The skill confirms it rather than inventing busywork.

Now point it at an older project. This is where it earns its keep. A trimmed report from a content site that's never been tuned:

vercel-optimize — old-blog

Investigated 9 routes. Ready recommendations: 3. Needs more evidence: 1.

1. /  (root layout)
   Signal: ISR writes ~1,400/day against content that changes weekly.
   Cause: a footer component invalidates the page cache on every render.
   Fix (ready): cache that component separately with a 24h life.
   Maps to: Section 3.3, ISR Writes.

2. /api/posts
   Signal: 40k function invocations/day, p50 320ms, all reads.
   Fix (ready): wrap the post query in a runtime cache; keep writes uncached.
   Maps to: Section 3.2, Runtime Cache.

3. Build cache
   Signal: 0% cache hit across the last 12 builds; duplicate install work.
   Fix (ready): dedupe the install step; restore the cache key.
   Maps to: Section 4.3, Build Minutes.

Every one of those recommendations is a lesson you already did. You don't have to trust the tool blindly. You can read finding #1, recognize it as the exact problem from the ISR Writes lesson, and know the fix is sound before you open the file.

Done-When

• The skill is installed and /vercel-optimize runs without erroring
• You've generated a report for Saturday and confirmed it's mostly clean
• You've generated a report for a second, un-optimized project
• Every "ready" recommendation is matched to the lesson that taught it
• You've made an accept-or-reject call on at least one recommendation and can explain why

Troubleshooting

The skill stops and asks for metrics instead of producing a report.

That's the design, not a bug. It won't audit a project it can't measure. Either the project lacks Observability Plus, or it has no production traffic yet. Turn on the add-on, or point the skill at a project that's actually serving requests. The code-only audit it offers as a fallback can't answer the real question, which is which change will move your production numbers.

The report told me to enable Fluid Compute, but I turned that on in Lesson 3.1.

The skill treats your project config as ground truth, so this shouldn't happen on a correctly linked project. If it does, the skill read the wrong project's settings. Confirm the directory you ran it from is linked to the right Vercel project (vercel link) and run it again.

A recommendation I think is correct landed under "needs more evidence."

The skill downgrades findings when follow-up metrics are too sparse to prove the change is safe, for example a slow route that might actually be an error spike on one deployment. You learned the concept, so your judgment may be ahead of the available data. File it as a ticket and revisit once the route has more traffic.

Solution

Install the skill from any Vercel project directory:

npx skills add vercel-labs/agent-skills --skill vercel-optimize

Then run it:

/vercel-optimize

The skill's value isn't the run, it's reading the report against what you now know. Here's the map between what it recommends and where you learned it:

Six of this course's cost lessons line up with the skill's most common findings. That's not a coincidence. The skill encodes the same playbooks Vercel's support and field engineers use, and so does this course.

The difference is scale. You hand-tuned one project and learned every lever doing it. The skill takes that same workflow and runs it against the projects you'll never get around to auditing yourself. Saturday was the training. This is how you apply it to everything else you own.

That wraps Section 4, and the cost arc with it. Sections 5 and 6 move to plan-tier features: enforcement, real RBAC, and the enterprise controls for compliance and scale.