Verify a PR's UI end to end
A screenshot isn't evidence by itself. Confirm the PR's identity, open the real preview, and cross-check visual, frontend, and end-to-end behavior separately before calling it done.
Copy this prompt to start your first task:
What is this workflow?
"Verify a PR's UI end to end" is the recurring job of turning a PR link into a real verdict instead of a single screenshot. The teammate confirms the PR's identity — link, branch, head commit, merge status, CI status, and preview URL — then captures real, labeled screenshots of exactly the states the request calls for, and reports back three separate results (visual, frontend implementation, and end-to-end) instead of one collapsed "looks good." If something blocks verification — a login wall, a build failure, a fixture mismatch, a missing dependency, or a backend that isn't running — it names the blocker instead of guessing. Every check updates the same Artifact link, and an optional watcher can re-verify automatically whenever CI, the preview, or the head commit changes.
This teammate reads PRs, runs tests, opens previews, takes screenshots, and reports on its own. Five things always wait for a human: merging the PR, pushing to or rewriting the branch, changing shared preview configuration, publishing to production, and requesting or expanding repo write access.
How to use this workflow
Hire a Full-Stack Code Review Expert, not a screenshot tool
Open AI Teammates in the sidebar, click Hire AI Teammate, and pick the Full-Stack Code Review Expert template. Its default bio is generic reproduction-and-report work. Replace it on the Profile step so it knows this job is verification of a specific PR, not a general check-in:
Connect GitHub
The teammate needs read access to PRs, commits, checks, and deployment URLs. A workspace admin installs the GitHub App once (Settings → Integrations), then grants this teammate the repo. The grant narrows which repositories the teammate can reach, not the permission level — the teammate's token carries whatever permissions the installed GitHub App has, so if the App was installed with write access for coding teammates, this teammate technically has it too. The boundary that keeps verification read-only is the bio above ("you never push, merge, or rerun anything"), so keep that line in. Connect GitHub →
Set up two preview paths
The default path is the hosted preview: open the deployment URL from the PR's checks, wait for the target component to actually load, and screenshot exactly the states the request called for, never just the homepage.
The fallback is a local device, for when the hosted preview sits behind a login wall the teammate can't get past. In Settings → Devices (a personal setting, not a workspace-admin one, any member can add their own), click Add a device and run the connect command on a machine with the project's toolchain already installed. When hiring or configuring the teammate, the Engine step's Runs on field lets you point it at that device instead of Helio Cloud for this kind of work. Full setup: Run on your own machine →
Send one complete verification request
A request missing the target state or the delivery location isn't ready to run against, it just invites a guess. State the PR, the scenario, the expected state, what's allowed, what's off-limits, and where the report should land:
Split the conclusion into three layers
A single "looks good" hides exactly the failure that matters most: visual evidence and implementation correctness can diverge. If a preview fixture defaults canEdit to true, a screenshot meant to prove the read-only state will show edit controls that shouldn't be there, even though the frontend code and its tests are completely correct. The right conclusion isn't "broken" or "works," it's "frontend implementation and tests hold up, but this preview's fixture can't produce valid visual evidence for the read-only state":
Publish the report, and keep it on one link
The report goes out as an Artifact, visible to your organization, not the public internet. A follow-up check on the same PR updates that same artifact instead of creating a new one, so anyone with the link already open sees the latest result on refresh.
Automations
Turn recurring verification into an automation instead of re-running it by hand. Open Automations in the sidebar and click Create via Chat. On Home, choose the teammate and send the prefilled scheduled-task starter. When the interview asks what to schedule, describe the recurring verification below:
The same shape covers two other cases worth setting up once you're doing this regularly: re-running the verification matrix and refreshing the same artifact whenever a new commit lands on a passing PR, and a weekly digest of open UI PRs that have gone stale (no review in days, red CI, a 404 or login-gated preview, or a report that's fallen out of date).
Approval: This flow runs on its own — reading the PR, running tests, opening previews, and screenshotting the requested states don't need your sign-off. Merging the PR, pushing to or rewriting the branch, changing shared preview configuration, publishing to production, and requesting or expanding repo write access always pause for a human instead. See Control for how approvals work more generally.
Tips for Better Results
| Tip | Description |
|---|---|
| State the PR, scenario, and expected state together | A request missing the target state or delivery location can't be run against — it just invites a guess. Give the PR, branch, expected behavior, what's allowed and off-limits, and where the report should land, all in one message. |
| Let it fall back to a device when the hosted preview is gated | If the hosted preview sits behind a login wall, connect a device under Settings → Devices and point the Engine's Runs on field at it, instead of settling for stale screenshots. |
| Read all three layers, not just one verdict | Visual evidence and implementation correctness can diverge — a fixture defaulting canEdit to true can make a correct read-only implementation look broken in a screenshot. |
| Keep re-checks on the same artifact | A follow-up check on the same PR updates the same link instead of producing a new report each time, so anyone with the tab open sees the latest result. |
Common Questions
Design
Back to the design use case overview.
Catch UI feedback and ship the fix
For UI feedback that hasn't turned into a PR yet.
Connect GitHub
Grant repository access to the teammates that need it.
Catch UI feedback and ship the fix
A daily digest pulls UI feedback out of chat, routes the small stuff straight to an engineer for a same-day PR, and sends anything ambiguous to an actual designer instead of a guess.
Industry & Specialized
Real Helio user cases across verticals: social media, e-commerce, recruiting, academic writing, and running a whole company as a solo founder.