Critique Is Now the Teammate Your Agent Calls
We rebuilt Critique around a single handoff: when a coding agent says it is finished, Critique independently reproduces, repairs, verifies, and returns proof.
The teammate your agent calls
Independent reproduction, repair, and proof — from one CLI handoff
critique.sh/new
The way software is made has changed faster than the way software is checked. Increasingly, a person does not write every line or inspect every diff. They direct an agent, trust that it finished, and move on to the next decision. That is productive right up until an agent is wrong in a way that looks complete.
We built a lot around the old answer: a broad product surface where humans came to inspect work. The useful insight underneath it was never the surface area. It was the moment of doubt: an implementation exists, somebody needs to know whether the claim holds, and if it does not, the next useful thing is a repair — not another comment.
A narrower job: finish the change
The new product has one primary action: critique finish. A coding agent has implemented a task, run its own checks, and reached a conclusion. Critique takes that candidate finish as an input, not as a verdict. It gets a separate pass over the change, reproduces the behavior it can, and returns a clear outcome with evidence attached.
What shipped in the new Critique
critique finishreturns a deterministic outcome, artifacts, changed paths, limits, and an exit code.--repair none,--repair pack, and--repair applylet an agent buy only the amount of repair it needs.--jsonis first-class, so a coding agent reads a contract instead of scraping terminal prose.
critique integrate --agent allinstalls managed finish skills for Codex, Claude Code, and OpenCode.critique loginopens a browser for one human approval, then gives the local agent a scoped machine credential instead of a browser session.- Model selection is explicit: use automatic selection or choose the model the run should use.
- Critique reconstructs candidate changes in disposable local workspaces for the deep local repair loop.
- Development and test env files can be used locally for validation but are excluded from patches, proof artifacts, and cloud uploads.
- A verifier-approved patch is the only repair that can be applied back into the caller’s working tree.
The interface is deliberately small
The first command is npm, because this product belongs in the environment where the agent already works. The only human step is approving access in the browser. After that, the coding agent can make the handoff itself.
Install once, let your agent call it
Install the CLI, authenticate once, then install the managed instructions into the coding agents you use.
npm install --global @critiquedotsh/cli
critique login
critique model auto
critique integrate --agent allThere is no workspace ceremony hiding behind that command. The agent receives the result it actually needs: whether a defect was reproduced, whether a repair was prepared or applied, what changed, what was rerun, and where the proof lives. If Critique cannot establish a trustworthy result, it says so instead of manufacturing confidence.
What we are optimizing for
The pivot is not “put the old application behind a terminal.” It is removing everything that does not strengthen the handoff.
| Keep | Remove from the critical path | Why it matters | |
|---|---|---|---|
| Independent verification | A second pass with evidence, a fresh verifier, and outcomes an agent can act on. | A human dashboard as the prerequisite for every run. | The buyer is increasingly the agent’s workflow, not a person looking for another screen. |
| Repair packages | The smallest patch, its checks, and a resumeable response. | Open-ended issue queues where the fix is someone else’s problem. | A discovered bug only creates value when the next action is ready. |
| Sandbox discipline | Disposable execution and local-only handling for development and test environment files. | Treating every repo run as interchangeable cloud prompt context. | Verification must fit real repositories without casually exporting their working secrets. |
| One agent contract | CLI, JSON, exits, artifacts, and skills for the tools agents already use. | A bespoke interface each integration has to learn. | Distribution improves when Critique is a tool agents can call directly. |
Early access: GPT-5.6-Terra, on us
We are opening the new CLI to early users with free GPT-5.6-Terra-powered capacity. Hundreds of millions of tokens are ready. This is for teams that are already asking coding agents to do meaningful work and want a serious finish loop around them.
The boundary matters
Critique is not a blank check to merge, push, or deploy. It does not take over ownership of the repository. Its job is to give the calling agent a stronger basis for the next decision: an independently tested outcome, a repair package when one is justified, and proof that can be inspected later.
The full reproduce-repair-verify path launches locally because that is where a repository’s actual test configuration and safe development context already live. Remote execution remains a separate, explicit path; we will widen it only where the same evidence and safety contract can hold. That constraint is a feature, not a gap we plan to paper over with a flashy demo.
Who this is for first
Small teams shipping at agent speed who need a second set of eyes without adding a new review ritual.
People who already use Codex, Claude Code, or OpenCode and want a standard finish command in every serious repo.
Teams that need a reusable verification primitive inside CI, internal tooling, and supervisor-agent workflows.
Organizations that need the same proof-oriented contract with their own policy, controls, and rollout requirements.
Give your coding agent a teammate.
Install the new Critique CLI, approve access once, and let your agent make the finish handoff when it is ready.
Get early access