Critique.sh · Newest from the Leemer Group
48h cadence · v3.1 liveCode review,
as a system of record.
Critique reviews every pull request inside a real sandbox, stores the result as a first-class artifact, and publishes it back to GitHub. Built by the Leemer Group.
What it is
The review is the product.
Critique is a GitHub-native pull request review product. It clones the branch into an ephemeral sandbox, runs a coordinated set of specialist reviewers against the actual working tree, and returns a structured verdict — not a chat transcript, not a comment stream, but a durable artifact that the rest of the system can read, render, and act on.
Every run produces stored findings, a sub-agent trace, a command timeline, and a set of runtime checks. That artifact is persisted by the app, published to GitHub, and rendered on a review page a human can return to weeks later.
Critique is used by teams who want PR review to behave like CI: repeatable, inspectable, and owned by infrastructure rather than by whoever happened to be online.
Architecture
The control plane split.
v3.1 runs on a clean three-way separation of concerns. Each surface has one job. The boundary is strict on purpose.
Sandbox
Inspect · Write artifact
Clones the repo. Inspects the diff in context. Runs specialists. Writes the final artifact to /tmp/critique-review-output.json. The only surface that sees source code.
App
Persist · Publish
Reads the artifact. Stores it. Resolves identities. Publishes the review back to GitHub. Never inspects code directly — trusts the artifact contract.
Review page
Render · Hand off
Renders the stored artifact for humans: summary, findings with drill-down, sub-agent reasoning, command timeline, runtime checks. Handoff point into Remedy.
Final artifact contract
One file. The whole review.
If it isn't in the artifact, it didn't happen. The app will not infer, backfill, or decorate.
summary
short reviewer verdict
body
full review text as published to GitHub
findings[]
structured issues: location, severity, category, rationale
subAgents[]
specialist reviewers that ran with scoped outputs
commandTimeline[]
ordered shell actions with timing
runtimeChecks
build, test, and environment signals
Release cadence · 48 hours
Three releases in four days.
APR 10
V2Engine upgrade
Deeper specialist reviewers. Finding clustering. Drill-down into why a finding fired. Stronger evidence packaging.
APR 11
V3Operational review system
Stored artifacts, review-run pages, canonical review publication to GitHub, fix prompts, and the Remedy handoff.
APR 13
V3.1Sandbox-native final artifact
The sandbox now writes the full review to /tmp/critique-review-output.json. The app becomes a thin persistence and publication layer.
· Current
What shipped in v3.1
Architecture tightening.
Sandbox writes the full review artifact as its final step
Formal schema for summary, body, findings, sub-agents, timeline, runtime checks
App reduced to persistence, identity, and GitHub publication — no review logic
Review page reads directly from the stored artifact; no recomputation
Command timeline surfaces every shell action the reviewer took, in order
Runtime checks captured inline with the review, not in a separate job
Clean handoff contract into Remedy for any finding a human wants fixed
Backend-led fallback path preserved if sandbox-native execution fails
Feature set
What you get.
Sandbox-native review
Every PR is cloned, built, and read inside an ephemeral sandbox. The reviewer sees the real tree, not a diff fragment.
Specialist sub-agents
Security, correctness, performance, and style are separate reviewers with scoped context. Outputs preserved, not merged away.
Stored artifacts
Reviews are first-class objects. Re-open a review from last week and see exactly what the sandbox saw.
Command timeline
Every command the reviewer ran, in order, with timing. No hidden steps.
GitHub publication
Reviews are posted as native GitHub reviews with line-anchored findings. Works inside your existing PR flow.
Remedy handoff
Any finding can be handed to Remedy — the Group's fix agent — without leaving the review page.
FAQ
Common questions.
Does Critique replace human reviewers?+
No. It replaces the first pass — the one where a senior engineer reads the diff, builds the branch, and checks the obvious things. Humans review the review.
Where does the review actually run?+
In an ephemeral sandbox, one per PR. The sandbox clones the branch, runs specialists, writes the artifact, and is destroyed. Source code never leaves the sandbox boundary.
What's in the stored artifact?+
A JSON file with summary, body, findings[], subAgents[], commandTimeline[], and runtimeChecks. That file is the review. The app and the review page are both just readers.
How does Critique relate to Remedy?+
Critique finds things. Remedy fixes them. The review page is the handoff — any finding can be sent to Remedy as a scoped fix task, with the original finding attached as context.
A founder note
“The product is becoming more literal. Good infrastructure should become more literal over time. The component that inspects the repo should be closer to the component that explains what it found.”
Repath Khan
Founder, Critique
Try it on your repo