/vercel-audit

Make it your own.

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

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

What the agent does

1. Record team, project and revision, and inspect recent deployment metadata.
2. Compare root directory, build/install command, output directory, framework preset and runtime against the relevant package's scripts and configuration, and identify drift or unsupported assumptions.

Inputs

• project and repository plus reported deployment concerns.

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

Scope

Reads

Framework detection, root/build/output settings, runtime assumptions, and deployment configuration.

Writes

No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.

Mode

Inspect; project and repository plus reported deployment concerns.

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

• Setting/source/effective-value comparison with drift findings, unavailable observations and ordered fixes.

How the work is checked

• A wrong monorepo root is identified; missing settings access is reported rather than assumed to match local defaults.

When to stop or clarify

• No settings edits or new deployment. Do not treat a successful old deployment as evidence the current revision is healthy.

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

Read team/project identity, root directory, framework preset, package manager, build/output settings and deployment SHA.

Method

Compare each setting to the workspace actually owning the app; distinguish monorepo install root from build root.

Pitfall

Relinking to inspect settings mutates project state; local hoisting can conceal undeclared dependencies.

Check

Produce an evidence-backed mismatch list and mark unavailable remote settings unknown instead of assuming local config is authoritative.

Situational decisions

When a monorepo's deployed root differs from the package under review: Trace install/build working directories and workspace dependency resolution before changing settings.

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