General · plan by default
/deploy
Prepare or perform deployment within the requested authorization
Use for an explicitly targeted deployment or its plan; vercel-preview is the Vercel preview specialization, and ml-rollout promotes model versions on prediction metrics.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select deploy from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv deploy, /just-vibe deploy and /jv:deploy in Claude. See shortcut setup and context examples.
/just-vibe:deploy Prepare a staging deployment plan; identify the exact revision and rollback./just-vibe:deploy Deploy a preview whose build succeeds but startup health fails./just-vibe:deploy Plan deployment without provider access; do not claim a URL or deployed revision.What the agent does
- Resolve the target environment and confirm the immutable artifact or revision, its prerequisites, checks and health criteria.
- Before execution, resolve schema compatibility and identify recovery to the previous usable target.
- Execute the authorized steps and verify the deployed revision and health.
Inputs
- application, environment/account, artifact/revision, and desired deployment action.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Prepare deployment; execute only the deployment explicitly requested and authorized, including promotion separately when needed.
- Writes
- Inspect/plan: inspect or propose; save requested artifacts only. Apply: make the requested changes or execute the requested operation within its resolved target and limits. Local preparation does not authorize live, remote, destructive or paid actions; existing explicit session authorization still applies.
- Mode
- Plan deployment when asked for a plan; apply for requested deployment preparation or submission to a resolved environment.
- Prerequisites
- Resolve the user brief and inspect the relevant project or supplied evidence. External capabilities are optional unless the selected action actually needs them.
Expected output
- Target and revision with the deployment plan or the actual deployment ID/URL, health results, and the recovery path with its limits.
How the work is checked
- Successful upload without healthy startup is not completion; an ambiguous production target blocks execution.
When to stop or clarify
- Do not create paid resources, alter DNS, or promote previews implicitly. Report partial deployment state before retrying.
Handling missing context
- Infer
- Resolve the named files, existing scripts, current task and earlier corrections from the conversation and repository.
- Assume
- Use the narrowest interpretation that completes a reversible local task; state a consequential assumption once.
- Ask
- Ask when competing targets or incompatible success conditions would change the result; continue independent inspection first.
Technical guidance
- Evidence
- Resolve provider, project/environment, immutable candidate revision, authorization and current live identity.
- Method
- Prepare artifact, environment/schema compatibility and rollback target before the requested deployment action.
- Pitfall
- Deploying from a dirty tree or checking a moving alias can disconnect observed success from the intended artifact.
- Check
- Verify the resulting deployment identity and health at that revision; code rollback limits from data changes remain explicit.
Situational decisions
When submission times out with uncertain provider state: Look up the operation by revision or deployment ID before creating another deployment.
When the request is for local preparation or implementation: Prepare the requested build/configuration locally; a deployment request authorizes its named submission, while unresolved account, target or paid-resource choices must be settled first.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.