/verify

Make it your own.

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

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

What the agent does

1. Read the relevant package scripts and changed behavior before choosing checks. Identify scripts that install, deploy, seed shared databases or make external calls before running them.
2. Execute the relevant bounded checks with the active host tool and capture actual exit code, revision, output summary and any generated artifacts. Use existing evidence in inspect mode; checks requiring fixture writes need a scoped apply verification. Do not repair failures unless the user requested repair.
3. Keep failed, blocked and unrun checks separate from passes; identify pre-existing failures only with evidence. Stop repeating a passing check unless a new change or unresolved concern justifies it.
4. Only when an evidence report or durable acceptance tracking is requested, read the proofs guide and use its criterion, collection and report procedure. Preserve full relevant source/test/configuration identity, actual observations and evidence freshness. A deployed URL needs independent revision identity; local hashes alone cannot establish it. Separate human review from automated assertions and never invent user acceptance.
5. Report the checks actually completed and remaining limitations. If a proof report was created, recompute its freshness before opening it and include failed, stale, missing and human-pending criteria; ordinary verification requires no saved proof.

Inputs

• target change and claimed success criteria.

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

Scope

Reads

Relevant tests, builds, type checks, and runtime validation; no automatic repairs.

Writes

Run checks when verification is requested, using existing tooling and owned isolated fixtures. They may create disposable local test/build artifacts. Do not modify product source, install dependencies or contact live systems unless that scope is separately authorized.

Mode

Apply because checks may create artifacts; target change and claimed success criteria. Inspect mode reads existing evidence only.

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

• Criterion/check/result matrix with commands, exit statuses, revision, covered criteria and blocked or unverified gaps.
• Requirement-linked proof report with check output, optional screenshots, freshness, attributed human review and remaining gaps.

How the work is checked

• A failing command produces a failed result; unavailable dependencies remain blocked rather than skipped into an overall pass.

When to stop or clarify

• Do not run deployment scripts as verification. Separate pre-existing failures from introduced failures using evidence.

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

Map requested outcomes to artifact identities and available checks, including any human acceptance.

Method

Execute the relevant checks, record actual status/output and preserve requirement-linked evidence without replacing missing observations with assertions.

Pitfall

A green command on another revision or a screenshot of one state cannot establish all acceptance criteria.

Check

Check evidence freshness against files/revisions and report incomplete, blocked or human-accepted criteria distinctly.

Situational decisions

When a required check is unavailable or fails before exercising behavior: Mark that criterion unverified and report the prerequisite separately from product failure.

When automated behavior is correct but a subjective criterion is unresolved: Report the automated evidence and leave human acceptance pending rather than manufacturing a pass.

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