Vercel · apply by default

/vercel-build-fix

Reproduce and repair failed deployment builds

Use for a failed Vercel build; vite-bundle handles size and splitting of a successful build.

Make it your own.

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

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

Example · apply
/just-vibe:vercel-build-fix Repair the preview build failure using the supplied deployment logs.
edge · apply
/just-vibe:vercel-build-fix Fix a deployment where an omitted runtime dependency exists only through workspace hoisting.
blocked · inspect
/just-vibe:vercel-build-fix Diagnose from a build log without a valid Vercel token; do not deploy to test.

What the agent does

  1. Identify the failing deployment, SHA, environment and first causal build error. Compare repository/install root, build package, output path, runtime/package manager and resolved dependencies with the successful environment.
  2. Reproduce the failing boundary locally when possible using the same workspace command and versions. Check case sensitivity, hoisted undeclared dependencies, build-time environment names and generated-file assumptions before patching application behavior.
  3. Apply a focused fix and verify the corresponding build path. Keep local success separate from remote deployment verification; reuse the existing deployment/project identity and create a new deployment only when requested.
  4. Report the causal evidence, changed configuration/code, local result and the deployment/revision actually observed remotely. Redact values and do not download secrets as incidental diagnosis.
  5. Use the matching bundled evidence collector when available; read its result and limitations rather than treating exit zero as readiness. Revalidate identity before a dependent action.

Inputs

  • failed deployment, branch/revision, and build logs.

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

Scope

Reads
Repository/build configuration causing the failure; project settings changes require explicit target scope.
Writes
Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.
Mode
Apply; failed deployment, branch/revision, and build logs.
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

  • Fix, root-cause explanation, local check results, and deployment verification if authorized.
  • Causal build boundary, environment comparison, patch and reproduction outcome.

How the work is checked

  • A missing runtime dependency is resolved correctly; environment differences are not masked by hard-coded secret values.

When to stop or clarify

  • Do not deploy or alter production settings merely to test. Inaccessible logs limit the diagnosis explicitly.

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
Capture the first causal build error, deployed SHA, working directory, lockfile, Node version and variable names/scopes.
Method
Reproduce the failed build conditions locally where possible; test whether the failure is dependency resolution, compilation or missing configuration.
Pitfall
A later wrapper exit hides the initial cause; supplying a production secret locally can conceal a missing preview scope.
Check
Run the matching build and inspect the new deployment's build result at the changed SHA, keeping local and remote evidence distinct.

Situational decisions

When local build succeeds but deployment fails: Reproduce the specific environment difference before changing application code or adding dependencies.

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