How to Use Critique

Critique gives you two tools that work together or standalone:

• Critique CLI (critique) — runs independent reviews of your working tree. Installs in one command, requires no config, and finds what a glance at the diff would miss.
• CritiqueCode (critique-code) — an author agent that implements your changes, then is forced through the same independent review and verified-repair loop.

They are separate packages in the same npm org. You can use one, the other, or both. Most teams start with the CLI for pre-push reviews, then add CritiqueCode when they want the agent to both write and prove the code.

1. Using the Critique CLI

The CLI is the independent reviewer. It installs on your machine, inspects every uncommitted change, and returns a verdict with evidence. It never edits your working tree without your explicit approval.

Install and log in

npm install --global @critiquedotsh/cli
critique login

Login opens a browser window — approve there, and the CLI stores a machine key. No config file, no server setup.

Review before you push

Run this in any Git repository:

critique check

Critique looks at every uncommitted change — staged, unstaged, deleted, renamed, and safe new files. It reviews the complete repository, not just the diff. It finds problems a glance would miss, like a function caller you forgot to update in another file.

The result appears as a terminal card: verdict, key findings, and what changed.

Faster: the capsule-only glance

When you want a lighter check:

critique quick

This inspects only the change itself without full repository tools. Use it for a 30-second sanity check before critique check or a push.

Review with purpose

When you have a specific concern, tell Critique what matters:

critique review "Does the retry logic handle network timeouts correctly?"

Or use a focused pass:

critique cyber --intent "Probe the new login flow for vulnerabilities"
critique break --intent "Find edge cases in the payment queue"
critique performance --intent "Check the new search endpoint for bottlenecks"
critique security --intent "Threat-model the new auth flow"
critique stress --intent "Stress the queue state machine"
critique reliability --intent "Test retries for this worker"

Each focused pass adds specialist skills — a security pass thinks about threats, a performance pass measures complexity and latency.

Ask for a second opinion mid-work

You do not need to wait until you are done. Get an independent perspective while implementing:

critique ask "Am I handling the cancellation case correctly?"
critique ask "Which failure scenario should I test first?"
critique chat --session billing

These are read-only. Critique inspects the working tree and answers without changing anything. Named sessions persist across calls so you can ask, implement, and ask again.

Let Critique fix what it finds

When Critique finds a proven defect, it can prepare a repair. You control the mode:

# Review only — do not try to fix
critique finish --intent "Verify the checkout flow" --repair none

# Prepare a patch so you can inspect it
critique finish --intent "Verify the checkout flow" --repair pack

# Apply the fix only after a fresh, independent verifier approves
critique finish --intent "Verify the checkout flow" --repair apply

With --repair apply, Critique does three things in sequence:

1. Critic — reviews and finds defects
2. Repairer — produces a fix in an isolated workspace
3. Verifier — checks the fix in a fresh workspace with a different model

The fix touches your files only if the verifier passes. This keeps false positives out of your code.

Local or cloud?

Local is the default. Critique runs the pinned reviewer runtime on your machine in disposable workspaces. Your source code stays on your laptop.

Use cloud when you need a clean remote machine — your laptop cannot run the project, or you want a separate environment:

critique cloud "Run the real tests against this change"
critique finish --engine cloud --cloud-env test --intent "Check this change"

Cloud receives a protected snapshot of your working tree. Each critic, repairer, and verifier gets a fresh workspace. Only explicitly selected test environment values are sent — your local .env is never uploaded automatically.

Read structured output

Add --json for CI pipelines or coding agents:

critique review --json
critique findings <run-id> --json
critique proof <run-id>
critique recheck <run-id> --json
critique history

The JSON result includes stable finding IDs, changed paths, selected methodologies, model usage, and repair state. --events sends machine-readable progress to stderr while stdout stays one valid result.

Integrate with your coding agent

Run this once per repository:

critique integrate --agent all

This installs collaboration instructions for Claude Code, Codex, Cursor, Copilot, and OpenCode. The coding agent stays in the lead — it implements the task, asks Critique for second opinions while work is in motion, then requests an independent finish review when the change needs proof.

2. Using CritiqueCode

CritiqueCode (@critiquedotsh/harness, binary critique-code) is the author agent. It implements in an interactive session, then the controller forces it through the existing review and verified-repair loop. It is a Claude Code-style coding agent — not a rename of the CLI reviewer.

Install and start a session

npm install --global @critiquedotsh/harness
cd /path/to/your-project
critique-code

Or log in first for access to Critique Inference:

critique-code login

The terminal prints a URL and code, opens your browser, and waits. Approve on critique.sh/device. CritiqueCode stores a machine key under ~/.critique/code/ and uses Critique Inference for all model calls.

The session flow

Once the session starts, you see a wordmark, a compact live status, and a ▸ prompt. Type what you want to build:

▸ Add a retry with exponential backoff to the checkout endpoint

CritiqueCode implements the change in your working tree. When it believes the task is done, you run:

/review

The controller forces an independent review in an isolated workspace. If defects are found, a repair is prepared and verified in a fresh workspace before it touches your code. Promotion to merge requires the independent reviewer.

Key slash commands

Slash lines are never sent to the model — they are session commands.

Voice mode

Speak prompts instead of typing:

critique-code --voice

Transcription uses Critique Inference. Billing is $0.000003 per second of audio. No system ffmpeg install needed — CritiqueCode ships its own recorder.

Control from anywhere

CritiqueCode runs on your laptop but you can interact from other devices:

# Local browser interface
critique-code web

# Pair with your phone on the same Wi-Fi
critique-code remote

# Connect from critique.sh/code
critique-code connect

All three keep the kernel and file writes on your machine. The remote interface is just the control surface — no code runs on the remote device.

Skills

CritiqueCode ships built-in skills for code review, when to run /review, and TDD. It also loads skills from the same folders other agents use — no migration needed:

• Project: .claude/skills, .agents/skills, .codex/skills, .cursor/skills, .critique/skills
• User: ~/.claude/skills, ~/.codex/skills, ~/.critique/code/skills

Built-in skills win on name collision, so a third-party code-review skill cannot replace /review. List what the current repository would load:

critique-code skills

Commands reference

critique-code                          # Start an interactive session
critique-code login                    # Authenticate
critique-code web                      # Local browser interface
critique-code remote                   # Phone pairing
critique-code connect [CODE]           # Connect from critique.sh/code
critique-code review                   # Full review
critique-code repair <run-id>          # Apply a verified repair
critique-code chat                     # Read-only second brain
critique-code skills                   # List loaded skills
critique-code import-skills            # Copy discovered skills to ~/.critique/code/skills
critique-code --voice                  # Start with voice mode on

3. Using them together

The CLI and CritiqueCode are designed to work as a pair:

1. CritiqueCode authors — implements the change in an interactive session
2. The controller forces /review — runs the independent Critique CLI reviewer in an isolated workspace
3. Findings go to the repairer — proven defects are repaired in a clean workspace
4. The verifier checks the fix — a fresh model family validates the repair before it touches your tree
5. Promotion is /ship — merge only when the independent reviewer passes

You can also mix and match:

• Use the CLI for spot checks while CritiqueCode is working: critique ask "Is this approach sound?"
• Use CritiqueCode for the heavy authoring, then run critique cyber --intent "..." from the CLI for a specialist security pass
• Use the CLI's critique integrate to teach your existing coding agent when to call Critique — without switching to CritiqueCode

The bias boundary

The separation is what makes the result trustworthy:

• CritiqueCode (author) owns the task, works in your tree, and knows what it intended
• Critique CLI (reviewer) sees the repository and the task contract, but never sees the author's transcript, plan, claims, or confidence

The reviewer decides what the repository actually proves — not what the author thought it did.

Which one should you use?

Common questions

Is my code safe with local reviews? Local reviews never leave your machine. Critique creates a temporary copy of your repository, reviews it there, and deletes it when done. Cloud reviews upload a protected snapshot that is deleted after the run. Source code is never used to train models.

Do I need to configure anything? No. critique check and critique-code work with zero configuration. Add critique init for review policy and critique integrate for coding agent instructions when you need them.

What about huge projects? Critique works on repositories of any size. The reviewer explores only relevant context — callers, tests, schemas, and configuration — not every file.

Can I try before I buy? Yes. Install the CLI (npm install -g @critiquedotsh/cli) or CritiqueCode (npm install -g @critiquedotsh/harness) and run critique check or critique-code in any project. Credit for model usage is included with your Account.

How is CritiqueCode different from the CLI? The CLI is the independent reviewer — it inspects code and returns findings. CritiqueCode is the author agent — it writes code in your working tree and is then forced through the CLI's independent review loop. They are separate packages (@critiquedotsh/cli and @critiquedotsh/harness) that can be used independently or together.

Related

• Critique CLI Reference — full command reference
• CritiqueCode — author agent details
• Independent verification — how evidence works
• Getting started — quick setup guide