Critique 0.2: Review Less, Test the Right Risk
Quick confidence for routine changes. Stronger proof, security probes, and resilience testing when the change deserves it.
Four ways to challenge a change
Quick confidence, task-aware proof, security probes, and resilience tests
critique.sh
The old CLI was capable, but it made the important choices hard to discover. A developer or coding agent could finish a task, see a small command list, and still have to guess whether a routine change needed a quick check, a repair package, a security review, or an attempt to break the failure path. That is too much ambiguity at the exact moment a change needs an independent challenge.
A command for the question you actually have
The new command palette
All four modes use the same evidence-first verification contract. Pick the lens that fits the change instead of asking a generic review bot to guess.
critique quickcritique quickis the default for low-risk changes and routine pre-push confidence.- It runs a bounded review-only pass with a 180-second default budget.
- It always uses
--repair none, so it cannot modify the working tree.
critique finish --intent "…"verifies the change against the claim you made.- Choose
--repair none,pack, orapplyaccording to the authority you want to grant. --jsonreturns a stable result for a coding agent, CI wrapper, or local script.
critique cyberconcentrates the pass on threats and authorization boundaries.critique breakcombines stress and reliability lenses for retries, recovery, interruption, and rollback.- Both begin with an explicit intent so the reviewer attacks the behavior that actually changed.
Quick means read-only
A fast check is useful only when it is safe to run habitually. critique quick maps to finish --repair none and rejects an attempt to add a repair mode. It is for the moment after a small refactor, a test adjustment, or a contained UI change, when you want an independent set of eyes without asking the tool to make a change on your behalf.
Security and failure paths deserve their own passes
“Review the change” is a poor prompt for a new authorization flow or a multi-step upload retry. Those changes have different failure modes. The security mode puts attention on the trust boundary. The resilience mode asks what happens when the normal flow is interrupted, retried, or forced to recover. The aliases make those choices discoverable in the terminal, while the underlying focus flags remain available for more specific combinations.
Keep the full control surface when you need it
Aliases are the starting point, not a restriction. Compose focused checks on the primary command for an unusual risk profile.
critique finish \
--focus security \
--focus reliability \
--repair none \
--intent "Review the webhook delivery change"One evidence contract behind every mode
The modes change the question, not the trust model. Critique reconstructs candidate work in a disposable local workspace for the deep local loop. Development and test environment files can hydrate that local validation context but are excluded from patches, proof artifacts, and cloud uploads. A repair is not accepted just because a reviewer suggested it: the verifier must independently clear it before Critique can apply it.
The terminal now teaches the workflow
We also rebuilt critique --help around decisions, rather than an undifferentiated list of flags. It starts with the routine paths, then separates deeper passes from evidence, recovery, and team setup. On an interactive terminal it has a more readable visual hierarchy; in logs or when NO_COLOR is set, the same guidance stays clean and portable.
- 1Is this a low-risk change and you only need a second look?Run
critique quick. It is intentionally read-only. - 2Do you need a proof bundle or a bounded repair suggestion?Run
critique finish --intent "…" --repair pack --env auto --json. - 3Did the change introduce a trust boundary or a dangerous failure path?Run
critique cyberorcritique break, then inspect the returned proof before accepting a repair.
Visible to the agent, not buried in a README
A command only matters if the person or agent at the keyboard can find it. The new modes now appear in the CLI help, the Dashboard landing flow, the documentation, the README, the AI-readable llms.txt guidance, and the managed instructions installed by critique integrate --agent all. Codex, Claude Code, OpenCode, Cursor, and Copilot integrations can make the same risk-aware handoff without relying on a developer to remember a hidden option.
Challenge the change that is in front of you.
Install Critique CLI 0.2, run a read-only quick check for the routine work, and bring a sharper lens when the change carries real risk.
Read the getting-started guide