The problem this solves
A pull request that claims to fix audit findings carries an implicit promise nobody usually checks: that the deployed result actually resolves what the audit found. Reviewers read diffs, and diffs can look correct while the rendered page still misbehaves - a meta tag emitted twice, structured data valid in isolation but broken by a layout wrapper, a robots change that does something subtly different in production rendering. The gap between code that looks right and pages that behave right is where fix PRs quietly fail.
Verifying properly means loading the preview deployment and re-checking every original finding against it, one by one. It is exactly the kind of diligence everyone endorses and nobody budgets: tedious, repetitive, and easy to skip when the diff looks clean and the sprint is ending. So teams merge on visual inspection, the audit re-runs weeks later, and some findings are still there, now with a closed PR claiming otherwise, which is worse than no fix because it looks resolved.
This playbook makes the verification the deliverable. The preview gets audited against the original findings, each one is marked resolved or still failing with evidence, the verification lands as a comment on the PR itself, and the team gets the ready-to-merge call in Slack. The merge decision stays human; it just stops being made on faith, and the audit's findings stay fixed once they are marked fixed.
How the mission runs
- Locate the PR and its preview. The agent picks up the open site-fix pull request on GitHub and its Vercel preview deployment: the rendered, deployed version of the branch. The preview is what gets verified, because production behavior is what the findings were about in the first place.
- Replay the audit against the preview. Site Audit re-checks each original finding against the preview URLs: the metadata that was missing, the structured data that was malformed, the robots behavior that was wrong. Each check runs against rendered output rather than source, catching the class of fix that reads correctly and renders wrong.
- Score every finding. Each finding gets an explicit verdict: resolved, still failing, or newly regressed elsewhere on the preview. Verdicts carry evidence - what was observed at which URL - so a still-failing item is a reproducible bug report rather than an opinion, and a resolved one is a checkable claim.
- Comment the verification on the PR. The full verification lands as a comment on the GitHub pull request: the finding-by-finding scorecard with evidence, pinned to the exact preview deployment checked. The PR now carries its own proof of behavior, and any reviewer can see precisely what was verified and when.
- Post the summary to #dev. A concise summary posts to Slack: how many findings verified resolved, anything still failing with links, and the ready-to-merge call if the scorecard is clean. The team merges on evidence, and the person who would have spent an evening clicking through preview pages does something better with it.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
A verification comment on the pull request itself: every original audit finding scored against the live Vercel preview as resolved, still failing, or regressed, each verdict with evidence and pinned to the exact deployment checked. Plus the summary in #dev with the ready-to-merge call or the remaining blockers. The merge stays a human decision, now made against verified behavior rather than a promising diff.
Make it yours
- Trigger it automatically whenever a PR touching site templates gets a preview deployment, making behavioral verification a standing gate rather than an occasional favor.
- Extend the check beyond the original findings to a smoke pass over the site's key templates, catching regressions the fix introduced somewhere the audit never flagged.
- Route still-failing verdicts back as review comments on the specific commits, so the author gets actionable feedback in the diff instead of a summary to decode.
Frequently asked questions
Does this merge the PR when everything passes?
No. It comments the verification and posts the summary; merging remains a human act under your normal review process. The mission's job is to replace faith with evidence at the moment of the merge decision, and the decision itself stays with whoever holds merge rights.
Why verify the preview instead of trusting the diff?
Because findings live in rendered behavior. A diff can be plausible while the deployed page still emits duplicate tags, broken structured data, or wrong directives once templates, layouts, and build steps interact. The Vercel preview is the closest thing to production truth available before merge, so that is what gets checked.
What happens when some findings still fail?
The PR comment lists each still-failing finding with the observed behavior and URL, and the Slack summary flags the PR as blocked rather than ready. The author gets a reproducible fix list, the verification re-runs on the next preview after they push, and the scorecard converges to clean.