Vizzly
Use Vizzly as evidence for user-facing changes. Keep the repository's existing test workflow in charge of how the UI is exercised.
Prepare
- Confirm the repository uses Vizzly by checking its config, dependencies,
scripts, or
.vizzlydata. - Use the repository's established CLI invocation exactly. Otherwise, replace
vizzlyin these examples withpnpm exec vizzly; usenpx vizzlywhen the repository uses npm. - Do not install, initialize, log in, or change credentials unless setup is in scope. Never print or persist a token.
Inspect And Verify
For cloud API queries, selectable fields, or an authorized review decision,
start with vizzly api schema --json and follow
schema discovery.
Discover request details as needed instead of loading the entire OpenAPI document.
Use vizzly context ... --json for local evidence and human-readable context
output for guided inspection.
-
Choose the supplied cloud build or comparison when one is named. Otherwise, use current local evidence or find the relevant cloud build.
-
For cloud data, discover the relevant API operations. For locally saved data, request JSON context:
vizzly api schema --json vizzly context build current --source local --json -
Confirm the build, source, branch, timestamps, baseline, review state, and pagination before drawing conclusions. Follow the schema's page instructions for cloud data. Missing fields remain unknown.
-
For cloud data, discover the comparison and image operations from the schema. View the baseline, current, and diff images together. If an image cannot be opened, label the result metadata-only; do not call it visual verification.
-
Read image dimensions, viewport, browser, diff regions, fingerprint, and relevant history alongside the images. A prior approval is supporting evidence, not permission to approve the current comparison.
-
State observations before possible causes. Make the smallest justified change, rerun the owning workflow, and inspect the new evidence.
Guardrails
- Do not invent progress, ranking, review state, visual causes, or missing API values.
- Do not approve, reject, comment on, publish, or replace evidence unless the task explicitly asks for that mutation.
- Preserve thresholds, cluster sizes, signature properties, and other capture settings unless repeated evidence justifies a change.
- Prefer deterministic fixtures and existing user journeys over hiding a diff with broader tolerances or a new screenshot-only test.
- Report the comparison or screenshot identity, observed evidence, access limitations, and the command or link used.
Load A Reference When Needed
- CLI context: local and cloud evidence, build discovery, schema queries, review decisions, images, and TDD lifecycle.
- SDK capture: add or change screenshot capture code.
- Dynamic content: investigate unstable content and screenshot-specific tolerances.
- Setup and CI: initialize Vizzly or change CI.