Critique CLI Gets a Conversational Second Brain
Ask for an independent opinion while an agent is still working, then escalate to a bounded reproduce–repair–verify pass when the answer needs proof.
A second brain, not a second driver
Ask for perspective while work is moving. Escalate for proof when it matters.
critique.sh
This is deliberately not another agent that grabs the keyboard. The primary coding agent still owns the task, chooses the implementation, and communicates with the user. Critique can challenge an assumption, identify the risk worth testing, or make the case for a simpler design. When the question becomes “can we prove this works?”, the primary agent hands the change to the finish loop.
A second brain, not a second driver
A good coding agent should not wait until the end of a task to discover that it made the wrong architectural bet. The new conversational commands make a second opinion cheap at the point where it can still change the plan. Ask about competing designs, an uncertain diagnosis, a risky migration, or the edge case that feels too easy to wave away.
Keep a focused engineering conversation
Use a descriptive session name for related follow-ups. The CLI keeps a bounded local transcript scoped to the repository, and `--new` starts that named conversation fresh.
# Ask before deciding how to implement a risky path.
critique ask "What assumption are we making about retry ownership?" \
--session checkout
# Continue the same engineering conversation.
critique ask "Which failure should we test first?" \
--session checkout- Read the redacted working-tree capsule: changed paths, base reference, exclusions, tracked patch, and safe untracked text.
- Carry up to twelve local conversation messages for the same repository and named session.
- Separate inspected facts from inference, then suggest a next move when one follows.
- It cannot edit files, run shell commands, spawn tasks, browse the web, or read external directories.
- It is not a formal review result and does not grant permission to merge, deploy, or broaden scope.
- It does not replace the completion pass when executable validation is required.
When the review needs to be trusted
The finish loop is now stricter about what a budget means and what a result may claim. A ten-minute limit is ten minutes for the whole proof loop—not ten minutes for each of the critic, repairer, and verifier. Each stage receives only the time left when it begins, and configured cost is accumulated after every stage.
If the remaining budget cannot support a repair or fresh verification, Critique stops. It reports an unverified result with a budget limitation instead of relabeling the situation as an infrastructure failure. An unverified repair is never applied back to the working tree.
Escalate the question into a proof loop
The final result remains machine-readable on stdout. Progress events stay separate so an agent or CI wrapper can observe the run without scraping a terminal card.
# Escalate only when the answer needs executable proof.
critique finish \
--intent "Prevent duplicate charges when an invoice retry races" \
--repair pack \
--env auto \
--json --eventsThe feature is not “more agents.” It is tighter authority and more honest outcomes around the agents already in the loop.
| Area | Current behavior | Why it matters |
|---|---|---|
| Stage permissions | Named critic, repairer, and verifier roles. Critic and verifier cannot edit; all stages deny nested tasks, external directories, and web access. | The critic can challenge the change without becoming an open-ended coding agent. |
| Time and cost | One deadline and one cost budget apply to the entire finish run. | A run cannot quietly spend three full budgets because it has three stages. |
| Repairs | At most one independently verified repair is applied per run. partially_repaired names a successful first repair with unresolved findings; repair_rejected names an attempted repair that failed verification. | One verified repair is evidence; claiming it fixed every defect is theater. |
| Cloud duration | The cloud finish worker now has a 30-minute execution window, rather than a five-minute ceiling below the normal local review budget. | A legitimate full review has room to inspect, test, and write its artifact. |
Machines need progress they can parse
Long-running local reviews should not force callers to guess whether silence means progress or a stall. Add --events to emit finish.event.v1 NDJSON records to stderr: phase changes, 30-second heartbeats, elapsed milliseconds, timestamps, and completion. The terminal finish.v1 document still arrives as one clean result on stdout.
That split is intentionally simple for a primary coding agent: follow the event stream while the work runs, then consume one stable result when it finishes. It is not a cloud event stream, and it does not turn local conversations into long-lived OpenCode server sessions. The local conversation is bounded transcript continuity; the API’s persistent-session model remains a separate product surface.
Give your agent a better next move
The useful question is no longer whether a coding agent can write code, inspect a diff, or run a test. It can. The question is whether it has a credible way to challenge its own plan before it commits, and a separate way to turn a completion claim into evidence afterward. That is the loop this release tightens.
Add Critique to the handoff, not the bottleneck.
Install the CLI, add the managed integration for the coding agents you use, ask when an independent perspective would change the decision, and finish when the result needs proof.
Read the CLI guide