Every capability,
with the diff it makes.
What Mantish does to a pull request, one capability at a time — and then the complete list of classifiers underneath.
features, annotated
This page exists so a claim is never only a claim — the views below are the real product, and the rule list at the end is the one the engine actually ships.
Semantic diff
ast · cross-file
Every change is classified by what it did: moved, extracted, renamed, modified, added, deleted. Matching runs across files, not only inside one, so a method that left one class and arrived in another is one move rather than a deletion and an addition.
A line diff cannot say those two halves are the same method, so you read it twice and then compare them in your head to be sure. That comparison is the work Mantish already did.
Structure view
outline · folded
Collapsed to its declarations by default; expanding one shows its diff without leaving the outline. It is not only for code — a YAML pipeline, a JSON manifest, a CSS or HTML file all fold into their own structure, which is usually the fastest way to see that forty shifted lines were one renamed block.
The outline is the navigation: nothing opens until you ask for it, and closing it puts you back where you were.
Diagram view
references
The same change set drawn as relationships instead of a list: which changed files reference which, which cluster together, and which are on their own. Clicking a node navigates to it.
Group changes
by category
Whitespace, reordered imports, a file whose content did not really change — you look at all of it anyway, because it is in the list and you cannot tell from the outside that it is nothing. Banded by category, each of those is one decision for the whole band instead of one per file.
The time a review costs is mostly spent on changes that were never going to change the answer.
Identical changes
dedup · bulk
A dependency bump, a namespace move, a signature that every call site had to follow: the change is the same in every file it touched. Mantish compares them, groups the ones that match, and shows the diff once with the list of files it stands for.
Each card is one change Mantish found byte-for-byte in every file under it. Pick a file to read it in its own context, tick it off when you have — or clear the whole group in one go.
Version="3.1.1"→Version="4.0.0"10 files <PackageReference Include="FluentValidation" Version="11.9.0" />− <PackageReference Include="Serilog" Version="3.1.1" />+ <PackageReference Include="Serilog" Version="4.0.0" /> <PackageReference Include="MediatR" Version="12.4.0" />Shop.Billing.Invoices→Shop.Invoicing5 files using System.Globalization;−using Shop.Billing.Invoices;+using Shop.Invoicing; using Shop.Core.Money;ApplyDiscount(order)→ApplyDiscount(order, customer)3 files var customer = await _customers.Get(order.CustomerId);− var discount = policy.ApplyDiscount(order);+ var discount = policy.ApplyDiscount(order, customer); order.Total = subtotal - discount;Grouped on the changes themselves, not on file names — files that merely look alike do not end up together.
Auto-mute noise
built-in tags
Every change carries the tags the classifier gave it. The ones you have already accepted a thousand times fold away until you ask for them — nothing is dropped, and expanding a group gives you its full line diff.
usually muted
rarely muted
your call
Rename
Symbol renamed without logic changes
Nothing here is fixed. Turn a classifier off for one review and back on for the next, or write your own when the built-in list does not describe your noise.
Spotlights
tag-driven
Auto-mute decides what folds away; a spotlight decides what cannot. A spotlighted change is pulled into a section of its own, marked in the file list and accented in the diff, however large the pull request around it is. The shortlist below is what ships — every other classifier can be spotlighted too, and you can write your own the same way you write a mute rule.
A dependency that moved a major version can be the first thing you see rather than the last — or spotlight whatever this particular project cannot afford to miss.
Files tree & tags tree
triage
The same changed files, filed two ways: by where they live, and by what they are. Tags are assigned automatically, so a large pull request can be triaged — security first, generated last — before you read a single line of it. Either tree keeps track of where you got to: tick off one file, a whole folder, an entire tag band, or the pull request in a single action, and a half-read folder says so rather than pretending either way. Both trees are below; switch between them.
Where the change landed. Folders fold away, and every file carries the tag it was given automatically — no one labelled these by hand. Tick off a file, a folder, or the whole pull request.
One file, one band: a file is filed under its most significant tag, so the bands add up to the pull request rather than double-counting it.
Watched paths
cross-repo
Watch a path: a folder, a glob, a single file. Mantish matches it against the open pull requests in every repository you have connected and lists the ones that touch it. Being left off the reviewer list stops being the reason you find out after the merge.
Matching runs against the pull requests themselves, across repositories — including the ones you would never have opened.
Ignore rules
globs · load time
A pattern list decides which files sit out of the change counters, out of identical-changes grouping and out of auto-mute. There is no reason to compare package-lock.json against every other file in the pull request looking for a group nobody wanted — so it is skipped, and the review opens on the files you are actually here for. The list arrives prefilled with the lockfiles every ecosystem generates and is yours from then on: delete a line and it never comes back.
Ignoring never hides a file from the tree. It drops the file's contribution to three things; the file itself is still there when you want it.
Structural analysis
roslyn · own engine
C# runs on Roslyn — the compiler's own parser and a full semantic model, so a symbol is followed rather than guessed at. Every other language is our own implementation: the parse, the facts read off it and the matching that turns them into moves, extracts and renames are the engine's work rather than a step handed to something generic. Files outside the list still diff — they just diff by line.
Any file your git host serves gets a line diff with word-level highlights. The languages above also get structural analysis — classes, methods, functions — which is what the structure view and the move, extract and rename detection are built on.
Works with every host
4 hosts
Pull requests, branches, iterations and comment threads behave the same on all four. A team split across two hosts reviews in one place, with one set of rules.
Review before you push
working tree · agent hand-off
A local repository reviews like a pull request: the working tree against HEAD, a linked git worktree, or any base…head pair — a branch, or one commit. The comments you leave are a review session kept inside the repository, rendered as a review.md checklist with each comment's file, line range and snippet. Copy the prompt, give it to your coding agent, and it works through the list and ticks the boxes; Mantish reads those ticks back and re-anchors comments whose file has moved on underneath them.
The review that used to wait for a pull request happens before you push — and what the agent changes comes back as a diff you review the same way as any other.
Every surface, one engine
desktop · terminal · vs code · jetbrains
What differs between the four is the shell. The classifier, the tags and the rules are the same binary underneath, and analysis runs on your machine in all of them. The JetBrains plugin is one plugin for the IntelliJ platform, so Rider, IntelliJ IDEA, GoLand, PyCharm and WebStorm all load it.
People and AI, told apart
threads · people vs ai
A pull request with tooling on it arrives as one column holding two different things: what a colleague actually asked, and what a bot or an AI reviewer suggested. Mantish recognises the automated authors and files their threads separately, so answering your reviewers is not an exercise in scrolling past a coverage report. Both lists carry the same open, pending and resolved filters — the split is who wrote it, not what you can do with it.
Recognition is by author, not by tone: the [bot] accounts every host issues, plus the review tools by name.
Themes, yours to change
editor · portable
Start from a built-in palette and change what you disagree with: the chrome, the diff tints, the status colours, and the syntax highlighting token by token. A theme is a file you can export, so a palette that suits your team travels to the rest of it instead of being described in a chat message.
If a theme is nearly right, it is a copy away from being yours — the built-ins are starting points, not a menu.
Colour-blind modes
a11y
Change highlights, badges and diff markers all switch together, so additions stay distinguishable from deletions without relying on red and green.
Code anonymization
privacy
Names become positional stand-ins on the way out: types read as Type1, methods as Method1, parameters and locals as var1. Framework and language names stay, because they say nothing about your product. Identifiers inside string literals are replaced too, and comments can travel anonymised, untouched, or be dropped entirely — whichever you set.
One name maps to one stand-in, on both sides of the diff and in every file — so the analysis still sees the same symbol move. It just never learns what you called it.
The full classifier list.
Grouped the way a reviewer meets them. Every one of these can be muted or pinned as a spotlight — the grouping is habit, not a setting you are stuck with.
Or skip the list entirely: describe what noise means to you and let an AI-classified rule decide per change — after the snippet has been anonymised locally.
Your PR is bigger than your change.
Mantish is launching in 2026. Join the waitlist to get early access.
One email when it ships. No drip campaign.