reviewlore

Teach your AI coding assistant what your reviewers keep asking for.

Every team has conventions that live only in PR review comments: add a changeset, put the test in the existing suite, don't expose that in the public types. Reviewers type them again and again, and Claude Code never sees them. This toolkit reads a repository's review history, finds the requests that recur across PRs and reviewers, and writes them as Claude Code rules that load when Claude works on the matching code — each one citing the review comments it came from.

What you get

A rule generated from vitest's review history (all examples):

---
paths:
  - "test/**/*.ts"
---
<!-- Generated by reviewlore (learn-from-reviews) from PR review history. Review, edit or delete freely. -->

# Write tests that fail without the change

A test for a fix or feature must fail when the change is reverted. Don't add near-identical tests that only vary input values; target the behaviour that could actually break.

**Why:** Requested on 3 PRs by 2 reviewers.

## Examples from PR review history

- > I would prefer tests that actually fail without you change (even if not always).
  — @sheremet-va on PR #10497: https://github.com/vitest-dev/vitest/pull/10497#discussion_r3339383006
- > Please, add tests that could actually catch bugs, most of the current tests are basically the same test with different values
  — @sheremet-va on PR #9662: https://github.com/vitest-dev/vitest/pull/9662#discussion_r2836501661
- > Please add test case which fails if it were simple `expected[key] = actualValue`.
  — @hi-ogawa on PR #9330: https://github.com/vitest-dev/vitest/pull/9330#discussion_r2645080058

Use it in Claude Code

/plugin marketplace add cloudhobbit/reviewlore
/plugin install reviewlore@reviewlore

Then, in any repository you work on, ask Claude to "learn our conventions from PR reviews" (or run /reviewlore:learn-from-reviews). Claude will:

1. fetch the last 6 months of review history (ask for a different window if you like);
2. merge comments that ask for the same thing in different words, and drop review logistics and one-off discussion;
3. show you the proposed rules, each with how many PRs and reviewers back it — nothing is written until you approve;
4. write them to .claude/rules/pr-feedback-*.md.

To see what it does first, run /reviewlore:learn-from-reviews demo: Claude works through a bundled sample of vitest's public review history and shows the rules it would propose, without a token and without writing anything.

Before you open a PR, ask Claude to "check my changes against past reviews" (or run /reviewlore:review-my-changes). It compares your branch with the repo's rules and recurring reviewer requests and lists what reviewers here are likely to ask for, each with a link to where they asked before — and says so plainly when nothing applies.

The synthesis runs in your own Claude Code session: no Anthropic API key needed. GitHub access comes from gh auth login or GITHUB_TOKEN (GitHub Enterprise and GHE.com work too: gh auth login --hostname <host>; GitLab reads GITLAB_TOKEN; see the CLI reference). The plugin also adds an MCP server, so Claude can look up what reviewers have said about a file before editing it.

Requires Node.js ≥ 20.11 on your PATH (the plugin runs the reviewlore CLI with node). Updates arrive with each release: run claude plugin update reviewlore@reviewlore, or turn on auto-update for the marketplace in /plugin → Marketplaces.

Use it from the command line

cd ~/code/your-project
npx -y reviewlore run --dry-run   # show the rules it would write
npx -y reviewlore run             # write them

Detects the GitHub repo from git remote, fetches 6 months of history and writes rules for recurring feedback. This path uses word-overlap clustering only, so it finds fewer rules than the plugin (vitest: 3 instead of 6), but it's deterministic and needs nothing but Node ≥ 20.11.

npx -y reviewlore generate --demo     # try it on a bundled sample, no token needed
npx -y reviewlore run --format agents # AGENTS.md, read by many other coding agents

Other formats: Cursor, Copilot, Aider, Windsurf, CONTRIBUTING.md, JSON, an HTML report. All commands and flags: docs/cli.md.

For teams

One person runs the skill and commits .claude/rules/pr-feedback-*.md. Everyone's Claude Code then loads those rules from the repo — teammates don't need the plugin, a token or Node.

• No token for everyone else. One person (or a scheduled bot) runs reviewlore publish-corpus (add --force to refresh it later) and commits the resulting .reviewlore-corpus.json. Everyone's plugin and CLI then work from that file — no GitHub token, no network.
• One ruleset for every reviewer. reviewlore export --to auto copies the reviewed rules to the other AI reviewers you use — GitHub Copilot code review, Claude Code Review, Cursor, AGENTS.md agents — path-scoped where the tool supports it, with the same source links.
• Keep rules fresh. Generated rules are tracked in .claude/reviewlore-rules.json. A scheduled workflow (examples/github-action/) refreshes the committed review history and opens a PR reporting which rules need attention — quotes aged out, paths gone, reviewers saying otherwise. Re-running the skill then proposes each update or retirement for you to approve; nothing is removed on age alone.

What to expect

• A handful of rules, not dozens. In the plugin a rule needs at least 2 PRs and 2 reviewers behind it; the CLI's default is 3 (reviewer, PR) pairs from at least 2 reviewers. On five public repos the plugin found 6 (vitest), 5 (pnpm), 3 (express) and 0 (commander.js, swr — too little review, or one reviewer doing all of it). Zero is a real answer; the tool doesn't invent conventions, and the plugin says up front when the history is too thin to expect much. On a one-maintainer project you can opt in to the maintainer's recurring requests (/reviewlore:learn-from-reviews single-maintainer); those rules are labelled "Maintainer preference" and say they have one reviewer behind them.
• Any language. When reviews are in German, Japanese or anything else — or just don't use the English phrasing the matcher knows — the plugin reads whole comments instead, and quotes reviewers in their own language.
• No generic advice, no contradictions. The plugin drops rules any engineer would follow anyway ("add tests"), and checks each proposed rule against your existing CLAUDE.md, AGENTS.md and rule files: duplicates are skipped, conflicts are shown to you instead of written.
• Measured, not guessed. Extraction is scored against 540 hand-labelled review comments in CI; on repos held out from tuning it picks up 64% of real review requests with 73% precision. How it works.
• Read before you commit. Rules are short and cite their sources, so delete anything that doesn't match how your team works.

Privacy

• No service of ours is involved. The toolkit runs on your machine; review comments are fetched from GitHub with your credentials and cached in ~/.reviewlore/. The token is never printed or written to disk.
• What reaches a model provider: with the Claude Code plugin, the review quotes Claude reads go to whichever provider your Claude Code uses, like anything else in the session. --llm sends cluster quotes to the Anthropic API. The plain CLI sends nothing anywhere but GitHub.
• What ends up in your repo: generated rules quote reviewers by GitHub handle, with links to the comments; a published corpus holds all the fetched comments (scanned for credentials, which are redacted). Review both before committing to a public repository.

More

• CLI reference · How it works · Troubleshooting
• Real-repo examples · Changelog
• Contributing

MIT licensed.