Critique stopped wrapping the agent and started owning the review
The coding agent still writes the change. Critique now owns the reviewer runtime, evidence boundary, specialist workspaces, and independent verifier that decide whether the change is ready.
Critique
CLI runtime update
The reviewer owns the room
Author agent in front. Independent proof behind it.
critique.sh/cli
Agent harness · BYOA · Composer 2.5
Critique CLI no longer treats OpenCode as an executable it happens to launch. It ships a pinned reviewer runtime, drives it through the typed SDK, captures command evidence through a Critique plugin, and gives every review stage a fresh context. Claude Code, Codex, Cursor, or another coding agent remains the main agent. Critique is the independent reviewer and second brain.
The old shape was tempting. Let the coding agent finish, send a diff to another process, parse the output, and call the result independent. That works until the process, permission model, session state, and event format all belong to someone else. Then the reviewer is only as trustworthy as the wrapper around it.
We changed the ownership boundary. The main agent still has the keyboard. Critique now owns the thing that decides whether the keyboard produced a change worth trusting.
The parent-process trap
A parent process is not automatically a harness. If it shells out to an external executable, guesses the server routes, parses an undocumented event stream, and relies on a hidden permission switch, it owns the orchestration but not the runtime. Upstream changes turn into wrapper patches. A lost final event becomes a parser workaround. A permission decision becomes an environment variable that nobody can see in the review result.
That is a bad place to build an independent reviewer. The reviewer needs stable sessions, explicit agents, predictable permissions, and a place to capture what happened. It should not have to infer those things from a moving command line.
What Critique owns now
| Layer | Critique owns | Why it matters |
|---|---|---|
| Distribution | Exact OpenCode binary, SDK, and plugin versions are shipped together. | A reviewer cannot silently change because an ambient executable auto-updated. |
| Sessions | Critique creates, names, times out, reconciles, and closes typed SDK sessions. | The controller knows which stage produced which result without scraping a terminal stream. |
| Evidence | The bundled plugin records argv, exit status, duration, output digests, and tree state. | A model cannot turn “I ran the tests” into proof by writing it in JSON. |
| Judgment | Critic, specialist, lead, repairer, and verifier are separate roles with fresh contexts. | Agreement can inform adjudication, but only current evidence can promote a finding. |
The main agent stays in charge
Critique is not a replacement coding agent waiting for a ticket. Claude Code can ask a question, receive a challenge, change the plan, and ask again. The persistent second brain can inspect the repository, run bounded diagnostics through Critique, and delegate read-only exploration. It cannot edit the author tree or quietly become the owner of the task.
A collaborative agent loop
The task ledger gives both sides continuity. The reviewer projection deliberately omits the author's reasoning and claims.
# The coding agent owns implementation.
critique task start "Prevent duplicate charges when an invoice retry races" --agent claude-code --accept "A retry cannot create a second charge"
# Ask while the design is still changeable.
critique ask "Which failure should we test first?" --session billing
# Request proof when the claim matters.
critique review "Recheck retry ownership, callers, and tests" --jsoncritique ask when an independent perspective could change the next implementation decision. Use critique review or critique finish when the answer needs a fresh repository, executable evidence, and a result that another agent can consume without trusting the author narrative.The bias barrier is structural
The main agent can be Claude, Codex, Cursor, or a custom harness. The reviewer does not receive its transcript, plan, worklog, claims, confidence, or conclusions. It receives the task request and acceptance criteria as orientation, then derives its judgment from the repository and Critique-controlled checks.
- Complete repository in a disposable workspace, not a diff-only prompt.
- Deep recon through callers, tests, schemas, configuration, deployment, and operations.
- Separate workspace and fresh session for each specialist lane.
- Fresh lead reviewer reproduces and adjudicates lane candidates.
- Transcript and hidden chain of thought.
- Claims such as “tests pass” or “this is safe.”
- Plan, worklog, confidence, and collaborator conclusions.
- Previous reviewer output that could anchor the next finding.
Thirty-eight methods are code, not a badge
A review methodology is only useful when it changes what the reviewer does. The CLI now bundles all 38 methods in the published artifact. Each one contains an investigation approach, required evidence, and a disconfirmation path. Selection chooses which instructions enter a review. It does not pretend every method ran, and it does not manufacture 38 findings from a small change.
Teams can include or exclude methods in .critique/profile.json, choose focused or deep repository reconnaissance, cap findings, require reproduction, and select the verifier model. The profile is portable by design, so a future UI can export review behavior without becoming part of the evidence boundary.
A verifier that can disagree
A repair is not a success because the repairer says it worked. Critique prepares the patch in one workspace, then opens a fresh verifier session in another workspace containing the candidate plus the patch. The verifier runs the original reproduction and relevant regression checks through critique_check.
The default verifier uses a different model family from the repairer. The result also records the reset workspace, fresh conversation, prompt-cache boundary, and captured command evidence. If the evidence is missing or the verifier cannot establish independence, the repair stays rejected. That is not a fallback message. It is the result.
The trade-off is deliberate ownership
Bundling a runtime means pinning versions, testing upgrades, and carrying a larger package. OpenCode ships an agent loop that moves quickly, so Critique keeps a thin adapter and upgrades deliberately. We did not fork the loop or rebuild provider streaming. The differentiated work is above it: task continuity, fresh judgment, evidence, adjudication, and honest repair state.
That boundary also makes local proof real. The CLI is the parent of the runtime it owns, so command evidence can be captured locally without pretending that a remote sandbox is the only place a controller can observe a tool call.
Try the new loop
Install once, then let the agent call Critique
Use JSON for agent integrations. Use `--events` when the caller wants progress on stderr.
npm install --global @critiquedotsh/cli
critique login
critique init
critique integrate --agent all
critique doctor