/vercel-runtime

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select vercel-runtime from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv vercel-runtime, /just-vibe vercel-runtime and /jv:vercel-runtime in Claude. See shortcut setup and context examples.

What the agent does

1. The bundled Vercel collector covers build logs only, so its result is not runtime evidence. For runtime or function logs use the host Vercel connector or observability tools, or the installed CLI vercel logs after reading vercel logs --help: confirm whether that version supports a time window and which deployment it defaults to, since older releases only stream live logs briefly.
2. Correlate deployment, revision, request and time window, and inspect handler entry, environment presence, dependency waits and runtime-specific API support.
3. Separate cold-start, resource and network causes, and propose a focused reproduction or fix. Revalidate identity before a dependent action.

Inputs

• deployment, route/function, error window, and correlation IDs.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads

Runtime exceptions, timeouts, resource limits, and local/deployed behavior differences.

Writes

Inspect/plan: inspect or propose; save requested artifacts only. Apply: edit the requested local implementation and perform relevant bounded checks while preserving unrelated work. Live data changes, remote actions and paid jobs require their resolved target and existing session authorization.

Mode

Inspect; deployment, route/function, error window, and correlation IDs. Apply for requested remediation.

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

• Request/deployment identity, a supported diagnosis with log references and causal hypotheses, the discriminating probe, and repair, verification and recovery limits.

How the work is checked

• Build success is not mistaken for runtime health; a timeout has evidence identifying the waiting boundary.

When to stop or clarify

• Do not trigger billable/high-volume traffic or expose request data. Change code or configuration only in apply mode for requested remediation.

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

Inspect function logs and request IDs with region, runtime, payload size, duration and dependency timing.

Method

Separate cold start, handler CPU, downstream wait and connection acquisition; compare runtime APIs to the deployed function type.

Pitfall

A successful build proves no request health; an Edge/Node API mismatch needs a supported runtime choice, not suppressed errors.

Check

Exercise the original failing route with a controlled request and observe success/error/timeout behavior on the same deployment.

Situational decisions

When timeout logs contain no downstream completion: Treat the waiting boundary as evidence, not proof of which dependency caused the delay.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring