UI Testing
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 UI Testing?
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 UI Testing 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