PR UI Verification
helio / pr-ui-verificationA green build isn't the same as a working screen. Your AI teammate checks every PR against your design system, opens the live preview, runs the flow, and reports visual, frontend, and end-to-end results separately.
On every new PR to this repo, verify the UI end to end: confirm it matches our design system, open the Vercel preview, run the main flow in a browser, and post a report with visual, frontend, and end-to-end results as separate sections. Ask me what you need before you start.
Swap in your own repo, preview host, and the flow you want walked.
What is PR UI Verification?
A teammate that checks each PR against your design system, opens the live Vercel preview, walks the flow in a real browser, and posts a report with visual, frontend, and end-to-end results in their own sections. It reports pass or fail with evidence, and the merge decision stays with the reviewer.
What it does
Any chatbot reviews a diff once. Helio verifies every PR's UI as a standing job — from your context, kept current, delivered to you.
| Owns the job end to end | It runs the identity check, opens the live preview, walks the flow, and reports each result, rather than reading the diff and stopping. |
| Runs again without starting over | Saved once it works, it fires on every new PR on its own, not as a one-off you have to re-trigger. |
| Works from your context | It reads your GitHub repo, opens the Vercel preview for that PR, and checks the screen against your design system. |
| Keeps itself current | When your design-system rules change, it tracks the new tokens and components. You don't re-teach it your standards. |
| Lands where you work | The report is posted straight to the PR or to Slack, so a reviewer reads it without opening Helio. |
Three things it gets right
Opens the real preview
It opens the deploy preview and walks the flow in a browser, so it catches a broken screen the diff alone would miss.
Three results, kept apart
Visual, frontend, and end-to-end findings each get their own section, so a green build never hides a broken screen.
Checks your design system
It measures the screen against your tokens and components, so a spacing or color drift is caught against your rules rather than a generic heuristic.
What PR UI Verification connects to.
Questions
- Does it block the merge?
- No. It reports pass or fail with evidence and posts it on the PR, but the merge decision stays with the reviewer. It won't merge or block on its own.
- How is this different from CI passing?
- CI tells you the build compiled and the tests it has ran. This opens the live preview and walks the screen in a browser, so a layout break or a design-system drift a green build wouldn't catch still gets flagged.
- Does it need a preview deploy?
- Yes. It opens the Vercel preview for the PR to run the visual and end-to-end checks against the real build. Without a preview it can still run the design-system read on the diff, but the flow check needs a live URL.
- Why report visual, frontend, and end-to-end separately?
- Because they fail for different reasons and different people fix them. Keeping the sections apart means a passing end-to-end run never buries a visual regression the reviewer still needs to see.
Check every PR's UI before it merges.
Point Helio at your repo — it checks each PR against your design system, opens the preview, runs the flow, and reports visual, frontend, and end-to-end results separately.
Ask about this automation