AI-authored GitHub PRs
Click one button on a feedback report. Usero clones your repo, writes the change on a branch, and opens a PR linked back to the report. You review the diff and merge it. Nothing merges on its own.
Most feedback dies as a ticket. Someone reads it, files it, and three sprints later it is still sitting in a backlog nobody groomed. The gap between "a user told us" and "we shipped it" is where good feedback goes to rot.
A feedback tool that stops at a tidy inbox has handed you more triage, not less. You still read each report, decide if it matters, find the file, write the code, and push the branch yourself. The tool counted the votes and tagged the theme, and the actual work, the part that takes an afternoon, is untouched. So the backlog grows faster than you clear it, and the reports that would take twenty minutes to fix queue behind the ones that need a quarter. The thing you want is not another column in a board. It is the diff. You want to open a report and find a branch already waiting with the change in it, so the only decision left is whether the code is right.
How it works
Disclosure: I build Usero, so weigh that. Here is the actual path. You connect a repo once by installing the Usero GitHub App, which is how Usero gets the access to clone and open a PR. On any feedback report (or a cluster of duplicate reports) you click Create PR. Usero spins up a Claude Code container, clones your repo, reads the relevant code, and writes the change on a branch named feedback/<page>-<timestamp>. The dashboard shows live phases while it runs: cloning, analyzing, implementing, creating PR. When it finishes, a real pull request is open on GitHub with a title, a body that quotes the feedback and links back to the report, and the diff. You review it like any other PR, request changes if it is off, and merge when it is right. Usero never merges for you. The clustering and the inbox are there to feed this step. The PR is the point.
You do not get a summarized theme and a priority score and then go write the code. You get a branch with the change already in it and a PR open on GitHub. For the class of fix that is a copy change, a missing validation, a wrong default, or a small component tweak, the work is done before you open it. You read the diff and decide.
The PR body quotes the report and links back to it in the dashboard. When you merge, you know exactly which user request you just closed, so the loop from "a user complained" to "this shipped" is one click of context, not a manual cross-reference between your inbox and your git history.
When ten people report the same broken thing in different words, Usero clusters them and you open one PR against the cluster. One branch, one diff, and the fix answers all ten reports at once instead of you opening the same change ten times.
Every PR lands as a normal GitHub pull request on a branch. Your CI runs on it, your reviewers comment on it, and it merges through your existing branch protection. Usero adds a draft author to your workflow. It does not take the merge button away from you.
The honest objection
Honest answer: it depends on the change, and you should expect to review every PR before it merges. On small, well-scoped fixes (copy, a missing guard, a wrong default, a contained component change) the diff is often close to mergeable. On changes that touch a lot of files, depend on context the model cannot see, or need to match a house convention it has not learned yet, the first pass will need edits or a rejection. We are building toward a readiness check that declines the reports a PR cannot credibly fix, and a self-verify step that runs your tests before the PR is surfaced, so fewer broken drafts reach you. Today those are not fully in place, so treat the PR as a strong first draft from a teammate, not a finished change to rubber-stamp. It saves you the blank-page start, not the review.
FAQ
No. Usero opens the PR and stops. It writes the change on a branch and creates the pull request on GitHub, then it is yours: your CI runs, your reviewers comment, and you merge it through your own branch protection. There is no auto-merge path.
You install the Usero GitHub App on the repo you want to connect. That install is what lets Usero clone the code and open a pull request. You can scope it to a single repo, and you can remove the app at any time from your GitHub settings.
A branch named feedback/<page>-<timestamp> (or an insight/<title>-<timestamp> variant for grouped reports), a generated title, a body that quotes the feedback and links back to the report in your dashboard, and the code diff itself. You see it as a normal PR in the GitHub UI.
Small, scoped changes with a clear target work best: copy and label fixes, a missing validation or guard, a wrong default value, a contained UI tweak. Broad refactors, anything spanning many files, or changes that hinge on context the model cannot read from the repo are where the first pass needs the most editing.
The PR record moves to a failed state in the dashboard and you can retry it. Infrastructure failures (a container getting recycled mid-run) are tracked on a separate retry budget from real generation failures, so an infra hiccup does not silently burn your attempts.
Free tier. No credit card. Two-minute install. The AI opens the PR, you merge it.