visual-regression-testing

Visual regression testing

Design visual regression candidates around baselines, viewports, fonts, data, difference thresholds, and intentional changes, and output VRT-## findings. It only organizes traceable visual quality candidates; it does not execute tests, nor does it write a design checklist as coverage, pass, or release evidence.

When to use

• When you need to extract visual regression testing candidates from page inventories, baseline screenshots, viewports and browsers, fonts, test data, difference thresholds, design changes, and historical diffs.
• When you need to explain the rationale for selection, applicable constraints, evidence gaps, and minimal verification actions.
• When materials are incomplete but a limited initial version still must be delivered, and blocked or unassessed boundaries must be made explicit.

Not applicable to directly executing tests, generating behavior conclusions without sources, replacing a complete testing strategy, or accepting risk on behalf of a Human.

Output format options

• Default output is Markdown; use tables, JSON, or CSV only when the user explicitly needs them or the existing delivery format requires them.
• Separate static analysis, unexecuted items, evidence status, and Human decisions; when there is no execution evidence, keep them unassessed, blocked, or NOT_RUN.

How to use

1. Read prompts/visual-regression-testing.md, and provide the goal, scope, materials, environment, and existing evidence.
2. First complete the six-category input audit: known, missing, conflicting, stale, out_of_scope, and assumptions.
3. Use VRT-## to record the object, preconditions, concerns, source evidence, and verification method, and retain impact/priority, responsible role, closure conditions, and evidence status.
4. When materials conflict, constraints are missing, or there is no execution evidence, retain both sides and the open questions.

Domain execution key points

• Define the baseline key: page/version/viewport/browser/OS/font/theme/data, and check that both sides of the comparison use the same conditions; if conditions differ, first mark them as non-comparable or as an environment difference.
• Deliver the environment key, regional differences/thresholds, attribution evidence, and baseline decision table; a difference exceeding the threshold does not automatically equal a product defect, and updating the baseline must not mask defects.
• When forming domain candidates, you must read and follow prompts/visual-regression-testing.md 's domain operations and determination process, retaining legitimate controls, evidence gaps, and verification actions item by item.

Core constraints

• Do not execute tests, do not assume rules, versions, thresholds, data, or results that were not provided, and do not treat the number of candidates as proof of coverage.
• File existence, name matches, design declarations, or Eval configuration do not equal real execution evidence.
• Mark unknown items as unassessed, blocked, or pending confirmation; do not fill them in with common sense.
• Do not modify requirements, code, test assets, or the target system.

Pre-delivery self-check

• The six-category input audit has been recorded: known, missing, conflicting, stale, out_of_scope, and assumptions.
• Each VRT-## has a source, evidence status, impact/priority, responsible role, closure conditions, and verification method.
• Facts, inferences, recommendations, unexecuted items, and Human decisions have been distinguished.
• Design candidates have not been written as execution results, coverage proof, or release conclusions.

Reference files

• During regression, read evals/eval.yaml and matching cases; configuration does not prove real project results.
• Trigger validation uses evals/trigger-prompts.csv and evals/local-rules.json; when skill.selection evidence is missing, report BLOCKED.

Common Pitfalls

• When scope or evidence is incomplete, do not write method names, file existence, or candidate counts as proof that tests were executed, covered, passed, or released.
• Do not use common sense to fill in rules, thresholds, data, environments, or results that were not provided; retain unassessed, blocked, and to-be-confirmed items.
• Do not expand this Skill's specialized candidates into a complete strategy, complete test cases, actual execution, or a release decision.

Best Practices

• Complete the six-category input audit first, then choose the smallest, traceable, and verifiable scope of findings.
• For each finding, retain the source, evidence status, impact/priority, responsible role, closure conditions, and verification method, and clearly state the residual risk.
• Write verification recommendations as next-step actions, and do not elevate the Skill package structure, candidate counts, or local Eval configuration into genuine quality conclusions.