pr-genius

---

type: Knowledge Bundle

title: PR Genius — the board for the PRs you sent out

description: Project management for your outbound open-source contributions — not a code reviewer. Know which of your open PRs needs you today, and what to do about it.

version: 2.2.3

created: 2026-07-01

updated: 2026-10-17

author: zsxh1990

conforms_to: OKF v0.1 (Sudhakaran88/okf-conformance) + agent_guidelines extension

---

mcp-name: io.github.zsxh1990/pr-genius

PR Genius

> Somewhere in your GitHub there are PRs you have stopped opening.

>

> One needs a rebase you keep meaning to do. One has been red for four days and

> nobody told you. Three have sat untouched for three weeks. And one you avoid

> entirely, because opening it would mean confirming that it is dead.

PR Genius is the board for that work — the contributions you sent out into

other people's repositories, where you have no tracker, no standup, and no

clue.

It is not a code reviewer. By default it never reads your diff, and it will

never tell you your code is correct. There are good tools for that, and this is

not one of them.

Unlike PR-Agent or CodeRabbit, this tool does not read your diff. It does

not write review comments on your code, and it is not an LLM. It scores a PR

against 61 anti-patterns harvested from PRs that actually got rejected, and

answers a different question from the one a review bot answers.

It answers the question a working contributor actually has on a Tuesday

morning: **of everything I have sent out, what do I touch today — and what

exactly do I do about it?**

---

Why this exists

GitHub remembers the PR.

It does not remember why you closed your third attempt on a given repo.

What worked. What didn't. Which reviewer actually answers and which commented

once and vanished. Whether the thing that got you bounced last time was the

size, the missing issue link, or the tone.

That knowledge lives in your head. It dies when the session ends.

PR Genius is where it goes instead.

> A Repo Profile captures the what a project wants.

> A case study captures the how a contribution landed or died.

> Your own status history captures the then-what — how long it waited, what

> changed, whether it ever came back.

Neither a code reviewer nor a chat model can have the third one. They see your

PR once, in someone else's repo. This sees your portfolio over months.

---

What it knows

| It knows | Why it matters to you |

|---|---|

| How 67 large projects actually behave — merge rates, review cadence, what gets closed | You stop guessing what encode/httpx wants and start matching it |

| Why real PRs got rejected — written down, with the evidence | You stop repeating the mistake that already cost someone else three weeks |

| What your own PRs did over time — which state each sat in, for how long | You find out a PR died while it was dying, not three weeks later |

| The policy of the repo you are aiming at | A Fixes #N in the body is still the single most common reason a first PR gets bounced |

Numbers, for the sceptical: 753 loaded patterns, 190 harvested failed-PR

observations, 68 repo profiles, 302 reviewed cases. Those are receipts for the

sentence above, not the point of it — every one of them is verified against the

live tree on each release by scripts/verify_claims.py.

One of those corpora deserves a caveat: success-patterns/ is

retrieval/reference only and is not wired into scoring. It is browsable

context, not a positive-feedback system, and no verdict has ever been changed