/check

name: check
description: Independently check application acceptance criteria in a live browser or saved recording with the Vibium CLI. Use for a formal verification step in the development loop, with PASS, FAIL, or REVIEW and recorded evidence.

Check with Vibium

Use `vibium check "<claim>"` to hand a specific acceptance claim to a fresh verifier context. The coding agent builds and fixes the application; Vibium's verifier investigates the running behavior with constrained browser tools. Your own browser inspection does not substitute for this invocation.

Setup

Use the project's configured Vibium binary. Otherwise try `vibium`, `./clicker/bin/vibium`, then `./node_modules/.bin/vibium`. Confirm `vibium check --help` works. Local Chrome is the tested baseline for live checks. For initial live setup, run `vibium ready browser --json` with the selected engine/channel. It inspects browser and driver files without launching them or touching the current browser; launch and BiDi connectivity remain untested. Follow its install/fix guidance if needed. Saved-input checks do not require a browser; skip browser readiness for them.

For OpenAI, export `VIBIUM_AI_PROVIDER=openai`, `VIBIUM_AI_MODEL`, and `OPENAI_API_KEY`. For xAI, select `xai` and export `XAI_API_KEY` (for example `--model grok-4`). For Anthropic, select `anthropic` and export `ANTHROPIC_API_KEY`; for Google, select `google` and export `GOOGLE_API_KEY`. Set a model available to that provider. Leave `VIBIUM_AI_REASONING_EFFORT` unset for Anthropic/Google. `local` uses the compatible adapter, defaults to `http://127.0.0.1:8080/v1`, and requires no key. Never manage or install a model runtime as part of Check.

An OpenAI-compatible service uses `VIBIUM_AI_PROVIDER=openai-compatible` and `VIBIUM_AI_BASE_URL`. Use the project's existing configuration. Vibium loads `~/.config/vibium/ai.env` for empty AI variables; nonempty process environment still wins. If none exists, tell the user to run `vibium config init` and fill in that file — do not write credentials to it yourself. Never print or log credentials. Do not choose another provider or model to work around a missing configuration without the user's direction.

After loading settings, run `vibium ready ai --json` during initial setup or when provider configuration changes. Exit 0 and `result.ready: true` mean the configuration and provider tool round-trip passed; exit 1 includes failed checks and fixes. It makes up to two small model requests and does not launch or change a browser. It does not check the application or replace Check. Resolve reported setup problems before the browser workflow; do not rerun it before every claim when the configuration is unchanged.

Run accomplishes a browser goal; its `completed` result does not replace a Check verdict. Check never inherits Run's conversation. For guidance on Run and general browser automation, use the `browser` skill if installed.

For a user-requested provider comparison or eval, pass `--provider`, `--model`, `--ai-base-url`, and `--reasoning-effort` per invocation. Pass the same overrides to `vibium ready ai`. Changing provider clears the inherited model, endpoint, and effort, so supply a model and any custom endpoint explicitly. Same-provider calls keep unspecified defaults; use `--ai-base-url ""` or `--reasoning-effort ""` to reset them. Credentials stay in the runtime environment. Overrides do not change later calls or weaken Check's independence.

Development loop

1. Turn the requested behavior into a concrete, observable claim. Keep the acceptance condition faithful to the request. For example: “Changing the timezone persists after refresh.” State any boundaries needed for the task, such as inspecting a cart without proceeding to checkout. If several independent behaviors matter, check them separately. 2. Run the application and exercise the relevant flow through the existing Vibium CLI. Use `go`, `map`, `find`, `click`, and `fill`; inspect fresh refs after page changes. Reuse the current browser, page, and `--session` or `VIBIUM_SESSION` throughout setup and verification. Create a named session only when starting a new isolated test, not when verifying existing state. 3. Record the flow. If the user already has a recording active, keep it active. Otherwise start one with `vibium record start` (the default filename is unique) and stop/save the recording you started after verification, even when the check fails. Do not stop someone else's browser or recording. 4. Run `vibium check --json "<claim>"` in that same session. The command starts a fresh verifier conversation; do not send the builder transcript, source code, or a suggested verdict. It may operate the page to test the claim. Let it finish before continuing browser work. 5. Read the JSON result and report the actual verdict, concise evidence, and recording path. The Check group contains verifier-driven child actions. A passed check applies to the stated claim and observed session. 6. When a check fails and fixing the application is within the user's task, investigate the evidence, fix the cause, and rerun the original claim. Preserve the earlier result. Do not weaken the claim or retry unchanged behavior until a model happens to pass it. For REVIEW, address the missing evidence or report the limitation. Stop when the requested claims pass or a concrete blocker requires user input.

Browser cleanup

Check preserves an existing browser session. If it starts a browser itself, it closes that browser after saving any requested recording, on all verdicts and execution errors. Use `--keep-open` when a standalone check should leave the browser available for inspection or more work. Do not assume it stays open just because `--output` saved a recording. `--keep-open` is live-only and cannot be combined with `--input`.

Recording and report flags

Use `-o verification.zip` to record the verificatio