Mewtwo

Reviews a pull request when you label it, and stays quiet when there is nothing worth saying.

Mewtwo is a code review agent that lives on GitHub. Attach the initial-review label to a pull request and the webhook returns immediately while the work happens in the background: the diff is compressed to fit a token budget, then enriched with the things the diff does not show โ€” callers of the changed functions, the tests for those modules, the configs and docs that explain intent. Five to ten agents then run in parallel, one per dimension, while Gitleaks scans deterministically for secrets. A judge collects everything, deduplicates it, and scores each finding by whether the model and the scanner independently agree. What comes back is two things: inline comments the author can act on, and a summary comment telling the human reviewer where the risk actually is. It is an Elixir/Phoenix app on AWS ECS, one supervised process per review.

>_ Github๐“‚ƒโœ๏ธŽ Read the blog
Elixir ยท Phoenix + LiveView ยท AWS Bedrock (Claude) ยท Gitleaks ยท Postgres ยท AWS ECS

What it does

Reviews on a label, not on open

The pipeline only starts when someone attaches the initial-review label, so the decision to spend tokens stays a human one. The webhook answers 202 straight away and the review runs in the background.

Compresses the diff instead of truncating it

Large PRs are collapsed to fit the budget: unchanged context trimmed to a few lines, big unchanged regions summarised, repetitive changes grouped into one line. Changed lines are always kept whole; plain context is dropped first.

Fetches the context the diff hides

After parsing the changed symbols it pulls callers of the modified functions, the tests for those modules, and the configs and docs that explain intent โ€” ranked by relevance and stopped when the budget runs out.

Parallel agents, configured per repo

Five to ten agents run concurrently, each analysing one dimension with its own prompt and codebase rules. Which agents run is per-repo config rather than a fixed list, so a small repo does not pay for all of them.

A deterministic scanner next to the model

Gitleaks runs in parallel for secrets, supervised with three retries and skipped gracefully if it never succeeds. When the model and the scanner flag the same file, line and category, that finding is marked high confidence โ€” agreement is the cheapest defence against a hallucinated bug.

A judge, then two different outputs

The judge deduplicates findings, ranks them by severity and confidence, and splits them: high and medium severity become inline comments for the author, and everything else becomes a risk summary for the human reviewer.

Reviews go stale, not silently wrong

Pushing new commits marks a completed review stale rather than auto-rerunning it. Re-attaching the label refreshes it in place, so stale reviews never pile up on the same PR.

Prompts that argue for less code

Agent prompts carry a decision ladder โ€” does this need to exist, is it already here, does the stdlib do it โ€” so suggestions push toward deleting code rather than generating it. It cut token usage by roughly a fifth as a side effect.

How it works

  • Someone attaches the initial-review label to a pull request.
  • The webhook returns 202 and hands the review to a background job.
  • The diff, commits and PR metadata are fetched, compressed, then enriched with callers, tests and configs.
  • Agents run in parallel, one per dimension, while Gitleaks scans for secrets alongside them.
  • The judge deduplicates, scores confidence on model-and-scanner agreement, and ranks by severity.
  • Inline comments go to the author, a risk summary goes to the reviewer, and the run is stored with its token usage.

Silence over noise

The hard part of a review bot is not finding things, it is shutting up. A clean PR should get no comment at all, only high and medium severity findings belong inline, low-confidence findings stay in the reviewer summary, and there is a cap so nobody scrolls past thirty nitpicks to reach the real bug. Precision over exhaustiveness โ€” a bot that cries wolf gets muted, and a muted bot reviews nothing.

Safety boundary

Mewtwo can never manufacture a green light. It only ever posts as a COMMENT โ€” never an approval, never a request for changes โ€” and it does not touch commit statuses or checks. Its entire write access to GitHub is two endpoints: post a comment and update that comment. Nobody can merge because Mewtwo said it was fine.

Where it is still weak

It does not yet read the repo like a maintainer does: no ADRs or design docs, so intentional decisions still get flagged as mistakes, and PR descriptions and commit messages are fetched and then dropped, which is exactly where the reason for a workaround lives. Severity is an enum without definitions in the prompt, which makes ordering softer than it looks, and test coverage is inferred from whether test files show up in the diff rather than measured. Those are the next things, in that order.

Every chapter is a part of my journey. Thanks for being here! โ™ก