/vercel-release-check

Make it your own.

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

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

What the agent does

1. Resolve team/project, candidate deployment ID, immutable Git SHA and intended environment from observed metadata. Compare that identity with the tested commit, build output and required configuration names/scopes.
2. Check build completion, representative route/API health, asset content types, access protection and environment-specific behavior. Distinguish a protected preview from an unhealthy deployment; do not use a generic successful homepage as proof of the application journey.
3. Identify the previous known-good deployment and test the proposed recovery against schema/data and external effects. Reverting code may not restore data compatibility or undo published messages.
4. Produce a gate table tied to this candidate: criterion, evidence identity/time, pass/fail/unknown and blocking consequence. Re-read candidate identity before readiness is reported. Promotion, alias/DNS changes and rollback require their own authorized action/target.

Inputs

• candidate deployment, intended production target, health criteria, and previous stable deployment.

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

Scope

Reads

Readiness and promotion/rollback preparation; actual promotion is a separate authorized action.

Writes

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

Mode

Inspect; candidate deployment, intended production target, health criteria, and previous stable deployment.

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

• Candidate identity, evidence-linked release gates, concrete blockers or unknowns, recovery target/limits and readiness for the exact requested action.

How the work is checked

• All readiness evidence applies to the named deployment and revision; unknown health or incompatible recovery is not converted to a pass. No deployment or promotion is implied by an audit.

When to stop or clarify

• Do not promote or change aliases from a check request. Missing required health evidence means not yet verified.

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

Verify immutable candidate SHA, health evidence, environment requirements, compatible schema and previous deployment identity.

Method

State promotion gates and a recovery sequence that accounts for data changes and in-flight work.

Pitfall

Code rollback may fail once the schema or external effects have changed.

Check

Check the actual promoted alias/deployment after authorized action and preserve pending gates when protected or live evidence is unavailable.

Situational decisions

When rollback would restore code but not reverse a schema/data change: Mark that recovery gap and require an explicit compatible recovery plan.

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