Check

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 INCONCLUSIVE, address the missing evidence or report the limitation. Stop when the requested claims pass or a concrete blocker requires user input.