just-vibeVercel · inspect by default
/vercel-performance
Investigate slow routes using available measurements and logs
Use for measured deployment latency/cache problems; react-rerenders handles client render cost.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select vercel-performance from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv vercel-performance, /just-vibe vercel-performance and /jv:vercel-performance in Claude. See shortcut setup and context examples.
/just-vibe:vercel-performance Analyze these route timings; distinguish cached responses from cold execution./just-vibe:vercel-performance Compare slow preview requests with cached production responses fairly./just-vibe:vercel-performance Assess supplied timing samples without load testing or changing the paid plan.What the agent does
- Correlate timing with runtime and cache state, and compare like-for-like requests with matching regions, payloads and cache states.
- Separate cold start, warm handler, dependency, network and browser timing, and rank optimizations by evidence.
Inputs
- slow routes, deployment, workload, and existing measurements.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Server response, cold starts, caching, payloads, and relevant client delivery behavior.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Inspect; slow routes, deployment, workload, and existing measurements.
- Prerequisites
- Exact team/project/environment and deployment/revision when applicable; read access to relevant configuration/logs. Verify installed CLI/API support and framework behavior during implementation. Never print environment values or infer promotion authorization from a preview request.
Expected output
- Measurement conditions and distributions, the limiting boundary, and a bounded optimization plan or experiment.
How the work is checked
- Cache hits and misses are compared separately; a single slow sample does not become a universal latency claim.
When to stop or clarify
- Load generation belongs to test-load, and new remote profiling needs a resolved target and budget. No automatic paid plan upgrade or unrelated application rewrite.
Handling missing context
- Infer
- Read the linked project, team, framework, environment and deployment SHA from local config and supplied deployment evidence.
- Assume
- Diagnose locally with existing build scripts when deployment access is missing; do not infer a production target from a preview URL.
- Ask
- Resolve a missing deployment/team/environment before the dependent remote operation; names and scope suffice without exposing environment values.
Technical guidance
- Evidence
- Obtain equivalent revision/region/payload samples, cache status and cold/warm conditions.
- Method
- Attribute latency to network, application, data access and cache; optimize the measured dominant stage.
- Pitfall
- Comparing a cold miss before with a warm hit after does not demonstrate an improvement.
- Check
- Repeat matched conditions, retain error rates and tail latency, and verify cache changes do not mix users or stale personalized content.
Situational decisions
When a fast sample is cached and a slow sample is uncached: Report separate distributions and investigate cache eligibility before claiming compute regression.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.