Mind Synapse
Automated pull-request review that reports defects with evidence, and only approves when the evidence agrees.
Mind Code reviews a change the way a senior engineer does: it reads the diff against the repository's own standards, reports objective defects at file:line, and says what it could not check. Findings come from two places — static analysers, and expert runs where a model reports findings through a validated tool call — so a review carries both the mechanical checks and the judgement calls.
How a review runs
- Read the diff in context. The reviewer loads the changed files together with the repository guidance that applies to them.
- Collect findings. Static analysers produce typed findings. Expert runs submit theirs through a tool call, and every field is validated — a malformed entry is dropped on its own rather than failing the run.
- Judge. An approval policy and a verification verdict are evaluated independently.
- Publish. The review is posted on the pull request. It approves only when a clean approval and a passing verification agree; anything else is posted as a comment, with the decision recorded.
What the review looks like
The body is laid out for triage, answering two questions in order: what kind of problems are these, and which ones first.
- Category badges across the top, counted: Bugs, Rule Violations, Test Gaps, Design Issues. Only categories with findings appear.
- Priority sections below: Action Required (critical and high), Review Recommended (medium), Other (low).
- One row per finding, numbered worst first. The claim, its category and axis are the summary; the location, the failure scenario and the fix are inside. Past three rows, a section folds the rest away.
Severities are critical, high, medium and low. A finding's category is derived from what it already carries rather than asked of the model separately: a finding with a rule ID violates a rule, one on the tests axis is a test gap, design axes are design issues, and everything else is a bug.
Repeat runs stay quiet
A pull request pushed to five times should not collect five copies of the same finding — that is the failure mode that makes teams switch review bots off. Each run compares what it found against what earlier runs on the same pull request already said, then decides what to post, what to resolve because it is fixed, and what to suppress because a human dismissed it.
Decisions carry across pull requests
Suppressing by fingerprint within one pull request is correct but too narrow: the same objection on the next pull request has a different fingerprint and comes back as though nobody had ruled on it. Precedent applies what the repository has already decided to what the reviewer found, so a dismissed objection stays dismissed.
Your standards, written down
A rule is a convention the codebase already has and has not written down. Rules are loaded at review time and attached to the findings that violate them, so review comments cite the team's own conventions instead of generic best practice. Candidate rules can be mined from past review activity and promoted once you agree with them.
Run a review
mind review
In a repository with a pull request open, this reviews the current diff against its spec and the repository's rules, then prints the findings. The same pipeline runs in CI to post the review on the pull request.
Related: Specs — the requirements a review checks a change against.