built SwiPR — swipe-to-review GitHub PRs with AI context

paste any public repo and get a full review workspace. five ways to look at your PRs:

  • Swipe — card stack, J/F/Space to approve/reject/skip, AI panel loads risk score, contributor history, similar past PRs, and an impact graph on each card
  • Risk Matrix — PRs sorted into High / Medium / Low columns so you know where to start
  • By Contributor — grouped by author, useful for triage passes
  • By Category — grouped by label/type (bug, feature, docs, CI…)
  • Dependencies — DAG of which PRs reference each other, rendered with topo sort

everything is cached per PR so it’s not hammering the API on every view. also ships as a Claude MCP server — one config block and you can ask things like “what’s the risk on PR #1247 in resend/resend-node” straight from Claude Desktop.

BYOK if you self-host, shared credits on the demo.

Stack: Next.js App Router · Vercel AI Gateway · Neon pgvector · Drizzle · mcp-handler

Try it: https://v0-swipr-build.vercel.app
Repo: GitHub - nochinxx/SwiPR · GitHub

would love to hear from anyone wiring MCP into review workflows, also any sort of feedback is well appreciated. Thanks!

1 Like

Hi Nochinxx,

Nice idea. The “five views” framing makes the PR review flow feel much easier to scan than a normal diff wall.

One thing I’d consider adding is a small confidence/source indicator per AI comment, especially if the app is summarizing or flagging risky changes. For example:

- based on changed file only
- based on related files
- based on package/config context
- needs human verification

That could make the AI feedback easier to trust because reviewers can tell whether the comment came from local diff context or a broader repo read.

I’d also make “open original PR/file on GitHub” very prominent from every card, so the swipe flow stays fast without becoming a closed review surface.

2 Likes

Thanks, Ryu. Sure, I just added some of the source indicators. However, the idea is also that each user modifies the code so that the flags are more accurate to what they usually check for.

I’d also make the “open original PR/file on GitHub” more prominent.

Thanks!

1 Like

Hi Nochinxx,

That makes sense, and nice work moving on those changes so quickly.

I like the idea that teams can tune the flags for their own review style. My only thought would be to make the default rules very transparent, even if they are meant to be customized later. Something like a small “why this was flagged” note could help new users understand the baseline before they start editing it.

The source indicators already sound like a good step in that direction. I’m definitely not the expert here, but this feels like the kind of tool where trust and explainability matter almost as much as the AI output itself.

Really cool project — thanks for sharing it.

2 Likes