A failed check is a precise bug report. With automatic CI follow-up on, ProPR posts the failure on the pull request and an agent pushes the fix to the same branch. You come back to green checks and one more commit to review.
Automatic CI follow-up is off by default and set per repository. Turn it on where a red check means a real defect; flaky checks would only feed the agent busywork.
Slow or flaky checks that should never start a fix go under Checks that never block automation. See the follow-up docs for both settings.
When a check run or commit status fails on the pull request's latest commit, ProPR posts one comment: the check, the result, the commit, a link to the run, and the failure evidence from the check's annotations or output.
ProPR treats its own failure comment as a follow-up request; no label or trigger keyword needed. The agent reads the failure with the PR's context in an isolated workspace, ProPR pushes the fix to the same branch, and the completion comment explains what changed.
ProPR reports each failing check once per commit, and only on the PR's current head; a superseded commit or a closed PR starts nothing. The fix commit runs your checks again, and a new failure on it gets one new follow-up. Ultrafix pauses on red and resumes once the checks pass.
With the setting off, copy the failing output into a PR comment. The fix lands the same way, as a follow-up commit.
On public propr #2628, the Validate Changes check failed on a lint rule. ProPR posted the failure at 13:05 UTC; GPT-6 Astra brought VibeAgent.ts under the 400-line limit, and ProPR pushed fix commit 9296e95 at 13:08.
Red checks on your pull requests turn into fix commits on the same branch, each explained in a comment, while you review only what needs a human.
The
lintcheck fails:src/checkout/summary.tsexceeds the 400-linemax-lineslimit. Split the formatting helpers out without changing behavior.