vrt-migration-eval

Evaluates visual equivalence of framework or CSS-library migrations using pixel diffs and computed-style deltas.

22|1|Updated Mar 30, 2026
One-click install
npx skills add https://github.com/mizchi/vlmkit --skill vrt-migration-eval-mizchi
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: vrt-migration-eval
Source: https://github.com/mizchi/vlmkit/tree/main/.apm/skills/vlmkit/workflows/vrt-migration-eval
Command: npx skills add https://github.com/mizchi/vlmkit --skill vrt-migration-eval-mizchi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When you swap a frontend stack — Tailwind to vanilla CSS, a reset-CSS change, a bundler swap — the markup is deliberately rewritten, so a flat pixel diff drowns real regressions in 60-90% noise. This Skill structures migration verification around component bounding boxes and computed-style deltas so only meaningful divergences surface. ## Core Features & Use Cases - Compare mode: Deterministic capture of baseline and variant with pixel diff, per-section bounding boxes, and per-viewport computed-style diff, producing a numeric verdict. - Blind mode: The variant agent never sees baseline pixels and must converge from structural hints and CSD feedback over a fixed round budget, stress-testing the new stack's authoring ergonomics. - Subagent mode: Dispatches a fresh agent to run the comparison and write an unbiased structured verdict inside a longer chain. - Use Case: After porting a page from Tailwind to hand-written CSS, run vlmkit migration compare baseline.html variant.html --output reports/ and inspect the computed-style tables to find missing @media rules instead of chasing pixel noise. ## Quick Start Ask the agent to evaluate whether your Tailwind-to-vanilla-CSS migration is visually equivalent by running vlmkit migration compare on the baseline and variant pages with masked non-deterministic selectors.

Frequently Asked Questions about vrt-migration-eval

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a Tailwind to vanilla CSS migration visually?

Run vlmkit migration compare with the baseline and variant HTML files or URLs, plus an output directory. It produces a pixel diff, per-section bounding boxes, and a computed-style diff per viewport, which you format for review with vlmkit diff agent.

Why is a flat pixel diff misleading for framework migrations?

Migration rewrites the markup deliberately, so 60-90% of pixel differences are noise rather than regressions. Computed-style deltas per selector and viewport surface only meaningful divergence, such as missing media queries or wrong base rules.

What is the difference between compare, blind, and subagent modes?

Compare is the default deterministic mode producing a numeric verdict from both rendered pages. Blind hides baseline pixels from the variant agent to test convergence from spec alone, and subagent dispatches a fresh agent for an unbiased verdict inside a longer chain.

When should I not use migration evaluation for visual diffs?

Do not use it for a single CSS file edit, a page authored from scratch with no baseline, or CI regression tracking over time. Those cases belong to plain visual-diff, markup synthesis, or regression-watch workflows respectively.

Why does migration compare need the --mask flag?

Non-deterministic content like timestamps, marquee animations, and generated IDs creates cosmetic diffs that obscure real regressions. Passing --mask with those selectors excludes them from the comparison so the report reflects only controlled content.

Does migration evaluation require an API key?

Only the subagent mode invokes an LLM and needs GEMINI_API_KEY or OPENROUTER_API_KEY. The compare and blind modes are deterministic and run key-free against local files or dev-server URLs.