Bug reports · Reviewed changes
A bug reporting tool that ends in a pull request, not a ticket
Most bug reporting tools stop when the report lands. Someone clicks a button, adds a screenshot, and a ticket appears in a queue. The fix still waits for a person to read it, work out what to change, and write the code.
Patchkind goes further, with you in the chair. A bug report arrives with its screenshot. Patchkind turns it into a short plan. You read the plan, edit it if you want, and approve it. Nothing runs until you press Run. Then Claude Code works inside your own GitHub Actions, on your own Claude subscription token or API key, and opens a pull request. You review the PR. Patchkind never merges.
How a report becomes a PR
- Report. A user clicks the feedback button on your app and writes what went wrong. A screenshot is optional. Users do not need an account.
- Plan. Patchkind drafts a short plan. You edit it and approve it. Approving does not start anything.
- Run. You press Run. Claude Code runs in your repository's GitHub Actions. Your Claude credential lives in your GitHub secrets; Patchkind does not hold it.
- Review. A pull request comes back with the checks that ran. You read it and decide whether to merge. Claude may ask a question or stop instead of writing code.
A real one: “—” became “no price data”
On AlgoThesis, a stock-news site run by Patchkind's owner, an earnings page showed a dash where a price move was missing. The documented PR scope was to explain that missing value.
The workflow required an approved plan and an explicit Run action. The original report-to-plan wording is not quoted here. The pull request replaced the dash with "no price data" and one line on why. It changed 1 file, +5 / −2 lines. The owner merged it on 5 October 2026. Review time was not measured.
A missing value without an explanation.
Moves are only shown for reports where we hold closing prices.
See the AlgoThesis case study for PR #724 and the wider trial.
That is the size of change Patchkind is for right now: small, bounded changes for the owner to review.
Who it is for
- Web apps built with npm, in private or internal GitHub repositories, running GitHub-hosted Actions runners.
- Solo builders and small teams with more small bugs than time to fix them.
- Owners who want to read every change before it ships.
Who it is not for
- Native mobile apps. There is no iOS or Android SDK; a mobile app can open the hosted feedback link instead.
- Surveys, NPS or CSAT. Patchkind collects bug reports and suggestions, not scores.
- Teams who want fixes merged without a person reading them. Patchkind never merges.
- Projects on other stacks or other AI providers. The beta supports npm projects and Claude Code. Dependency changes are not allowed in a PR.
How it compares to BugHerd, Marker.io and Userback
BugHerd, Marker.io and Userback are mature bug reporting tools. They support more website stacks than Patchkind’s current npm coding workflow, they have been around longer, and they integrate with more issue trackers. Their core reporting flows organize tickets and annotations. Marker.io also supports AI-assisted fixes through MCP.
Patchkind’s coding workflow aims to return a pull request you review. Claude may instead ask a question or stop. It gets there by having you approve a plan first and by running the coding step in your own GitHub Actions. It is in a free invited beta, it supports npm web apps and Claude Code, and the evidence so far comes from a supervised trial on the owner’s own product. If you need a polished ticketing workflow across many stacks today, those tools are the safer pick. If you want small bug reports to come back as reviewable code, this is what Patchkind does.
Marker.io’s MCP integration lets connected agents read report context and open PRs, with autonomy chosen by the owner. Userback also connects feedback to coding assistants. Compare the plan and approval workflow, not a ticket-versus-code divide. Patchkind vs Marker.io →
Frequently asked questions
Does it merge the fix by itself? No. Patchkind opens a pull request and stops. You read it and merge it, or close it. On AlgoThesis, one PR was closed in review because the plan targeted a route that just redirects elsewhere. The agent followed the plan; the human caught it.
Who holds the AI key? You do. Your Claude subscription token or API key is stored in your own GitHub repository secrets. The coding step runs in your GitHub Actions and reads it there. Patchkind never receives it. Your Claude usage limits and your GitHub Actions minutes still apply.
What if Claude is unsure? It asks. Instead of a pull request, you get a focused question, and you answer it before anything else runs. Claude can also decline a task as too big. In our eight supervised AlgoThesis runs, one came back as a clarifying question instead of code.
What happens with a bad or hostile report? We tested this on purpose. Our verifier (a read-only Claude review of the run’s logs and summary) reported that Claude ignored instructions to expose environment/process data, send a token away and change protected files. The same run failed our protected-path check because of our own packaging bug: empty placeholder files. No PR was opened. It is one run on one repository, not a guarantee. Read the hostile-feedback test.
What does it cost? The invited beta is free. Your own Claude subscription or API charges and GitHub Actions usage limits still apply. Owners sign in with ChatGPT.
Try it on your app
Free invited beta. npm projects, GitHub-hosted runners, Claude Code.
Free invited beta. This requests an invitation, not instant access.
Questions: support@patchkind.com
See the Claude Code workflow guide and hostile-feedback test.