A local code reviewer that reads a git branch the way a careful senior engineer would, and refuses to hand you a finding it cannot prove.
A try square is the tool a woodworker holds against a joint to find out whether it is genuinely square, rather than merely looking square. That is the whole idea here. An AI can produce a review that reads well and is quietly wrong: a line number that drifted, a bug that a guard clause upstream already handles, a file it never opened. Trysquare is built so those failures are caught by the program rather than trusted away.
The app runs end to end, and the question it exists to answer is still open.
You can add a project, review one branch against another, watch the run, decide every finding, and export a report. A browser test walks exactly that path on every CI run, from an empty app to an exported file.
What is not settled is whether the findings are worth a person's time. Two
kinds of evidence exist, and they answer different halves of that question.
The free half: against a fixture with eleven planted defects (measured
2026-08-04) and two files that are deliberately correct, the pipeline carries
a correct review intact, finds all eleven, invents nothing in the clean
files, and discards no quotation as unverifiable. Run it yourself with
npm run demo:fixture -- --fake, which spends nothing. The paid half ran on
2026-08-04 on the maintainer's subscription: a haiku smoke was correctly
refused by the coverage law, the first full-strength run exposed a real
product bug that was fixed the same day, and the two runs after the fix each
found 8 of the 8 defects the fixture then planted, at the exact lines, with
nothing invented and nothing discarded, for about a dollar and five minutes
each. What no run settles is the judgment itself: whether those findings
read as worth a person's time is the maintainer's call, described in
docs/plans/FG2-CHECKLIST.md, and it has not
been made.
All twelve work packages are built: the review engine, the data and git layers, every screen, the design pass, the accessibility checks, and the interactive engine mode that runs a review from files in your own terminal instead of a subprocess. What remains open is judgment, not construction: the finding-quality verdict above and the design acceptance, both the maintainer's. The trail is in docs/plans/M4-FINISH-PLAN.md, and docs/PROJECT-STATE.md is the current-facts cache.
Treat this as usable by its author and not yet finished for anyone else.
Most AI review tools ask a model to look at a diff and report what it finds. That produces two failure modes that are hard to notice: the model skips things without telling you, and it reports things that are not true.
Trysquare is designed around the assumption that both will happen.
Bookkeeping is code, not judgment. Building the list of changed files and hunks, running the mechanical pattern sweeps, tracking which hunks have been dealt with, and checking cited line numbers are all done by the program. The model is asked for judgment, and only judgment.
Nothing is allowed to be silently skipped. Every hunk, every sweep hit, and every deletion has to end the review either attached to a finding or explicitly cleared with a reason. A review cannot reach the report while anything is undispositioned. This is enforced by a coverage ledger in the database, not by asking the model nicely.
Every finding is verified by someone who did not write it. Candidate findings go to a second pass in a fresh session with no access to the reasoning that produced them. Its job is to open the file, quote the actual lines, and try to kill the finding: is the code really there, does the mechanism really hold, is there a guard upstream that already handles it. Then the program checks the verifier's own work, byte-comparing the quoted code against the file at the cited lines. A finding with a line number that does not match dies regardless of how confident anything was about it.
A human decides what counts. Surviving findings are presented for you to confirm or dismiss with a reason. Only what you confirm reaches the report.
Reviewed code is never modified. Projects are cloned bare, reviews run in detached worktrees pinned to a commit, and the model gets a read-only tool allowlist. There is no code path that writes into a repository under review.
Both screenshots are of the seeded test fixture, whose defects are planted on
purpose and whose findings say so; they are produced by the browser suite on
every CI run rather than staged for the README, so what they show is the fake
engine's scripted review. The real-model smoke runs described in Status
happened locally and their evidence, including every finding's text, lives
under review/, which is deliberately not committed. No real model has
reviewed a real project through this app yet: that is the next gate, and it
is the maintainer's to drive.
The panel worth looking at is Coverage. It says how many files, hunks and sweep hits were accounted for, which is what separates "nothing is wrong" from "nothing was looked at". The two greyed stages at the ends of the timeline, Prepare and Audit, are the deterministic halves that no model touches.
Both themes are first-class and both are photographed and checked for contrast on every CI run.
You add a project by git URL and it is cloned locally. You pick the branch to review, the branch to compare against, one ruleset, a model, and how hard the model should think. You can add a sentence saying what the change was meant to do, which is treated as a claim to check rather than as an instruction. Before anything is spent, a pre-flight tells you what would be examined: the commits it would pin, the file and hunk counts, the sweep hits, and how many model requests it expects to make.
Rulesets are imported by pasting a markdown protocol document, which becomes numbered rules and process directives; the import is refused if it produces no rules. Each ruleset carries a tier, meaning rules for any code, rules for a technology, or rules for one project. Choosing several rulesets so the tiers compose in one review is designed but not built: today a review uses one.
The review then runs as a sequence of stages, mirroring a rigorous manual review: build the change inventory, classify risk, understand the code including the files it calls into, hunt adversarially against the rule database, review deletions as first-class changes, verify every candidate finding, and audit coverage before producing anything.
Two details worth knowing. Reviews can span two repositories at once, for the common case where an app and a package it consumes are changed together and a type change in the package is only dangerous at the consumer. And the way work is divided between requests adapts to the model you pick, because a model with a large context window can hold an entire rule set at once and a smaller one cannot. What never adapts is coverage: weaker models get more, smaller requests, never a shortened rule set.
- Node 22 or newer
- git
- Claude Code installed and signed in
Trysquare drives the claude CLI that is already on your machine, using
whatever credentials it already holds. It ships no model of its own and has no
account system, no server of its own, and no telemetry.
Be clear about what that does and does not mean. Reviewing code with a model means sending code to that model: when a review runs, the diff, the contents of the files involved, and your rulesets are sent to Anthropic by the Claude Code CLI, under whatever terms and plan you already have with them. That is inherent to the tool doing its job, not an extra. What Trysquare adds is that nothing goes anywhere else: no Trysquare service, no analytics, no third party. Your projects, review history, and findings are stored only in a local SQLite database and files under your own home directory.
npm install
npm run devThat serves the app on http://localhost:3000 and opens on the projects screen. docs/RUNBOOK.md walks through a first review from there, including which actions spend model usage and which do not.
To see the whole pipeline work without spending anything and without a model:
npm run demo:fixture -- --fakeThat builds two small git repositories with known defects planted in them,
reviews them end to end, and scores the result against the answer key. Drop
the --fake and it runs against a real model on your subscription.
Two environment variables matter. TRYSQUARE_DATA is the data root, holding
db.sqlite, projects/, runs/ and exports/, and defaults to
~/.local/share/trysquare. TRYSQUARE_CLAUDE_PATH is the binary reviews run
through, and defaults to claude on your PATH.
./verify.sh # the gate: lint, format, types, house style,
# private-material and hidden-file checks, unit tests
./verify.sh --build # adds a production build
./verify.sh --e2e # adds end-to-end tests (needs chromium, below)The end-to-end run needs a browser, once per machine:
npx playwright install chromium"Verified" in this project means exactly one thing: ./verify.sh exited zero.
The script checks each step's exit status separately from its output and also
scans that output for runtime error markers, because a step that prints a stack
trace and still exits zero is a failure. A step that hangs is a failure too,
not something to wait out.
The gate's own failure paths have been deliberately triggered and observed to fire. A gate that has never failed is assumed broken until proven otherwise, and the first version of this one did in fact pass a violation it should have caught.
The design is written down before it is built, and the documents are kept current rather than written once.
| Document | What it covers |
|---|---|
| docs/00-BRIEF.md | What the app is meant to be |
| docs/01-ARCHITECTURE.md | Topology, layering rules, on-disk layout, engine adapter |
| docs/02-DATA-MODEL.md | Schema, state machines, coverage invariants |
| docs/03-REVIEW-PIPELINE.md | The review stages and what is code versus judgment |
| docs/04-UI-DESIGN.md | Screens, states, accessibility |
| docs/05-TESTING.md | Test strategy and the seeded-bug quality gate |
| docs/06-MODELS-AND-PROFILES.md | Model discovery and how the pipeline adapts to model capability |
| docs/RUNBOOK.md | Install, start, and run a first review |
| docs/PROJECT-STATE.md | What is actually built right now |
| docs/plans/BUILD-PLAN.md | Work packages and milestones |
| docs/plans/M4-FINISH-PLAN.md | The remaining work to v1, item by item |
That is the short list. docs/README.md indexes every document, including the decision log and the gate ledger, and is the map to read first if you are picking the work up rather than picking it out.
Contributions are welcome. CONTRIBUTING.md explains how the
work is organised and what a change needs before it can be merged. The short
version: keep changes small, make ./verify.sh pass, and show evidence that
what you claim works actually works.
MIT.
This is an independent project. It is not made by, endorsed by, or affiliated with Anthropic. It runs the Claude Code CLI on your own machine under whatever plan you already have, and "Claude" and "Anthropic" are trademarks of Anthropic PBC, used here only to say what the tool talks to.