Getting Started with the Critique CLI

The Critique CLI is the independent reviewer your coding agent calls while it works. Claude Code, Codex, Cursor, Copilot, or another agent remains the main agent: it owns the task and edits the source tree. Critique owns the fresh review judgment, evidence, repair boundary, and verifier.

If you want Critique itself to author the change, that is CritiqueCode (@critiquedotsh/harness, binary critique-code) — a different package in the same npm org, not this CLI.

1. Install and initialize

npm install --global @critiquedotsh/cli
critique login
critique init
critique integrate --agent all
critique doctor

critique init creates a repository policy and portable .critique/profile.json. critique integrate installs the collaboration contract for the agents you use. It teaches the main agent when to ask for a second opinion, when to record a checkpoint, and when to request an independent review.

The CLI installs and owns its pinned reviewer runtime. There is no separate OpenCode installation step and no reviewer-engine choice to maintain.

2. Give the agent a durable task spine

Start a task when the implementation will involve decisions, checkpoints, or a later repair loop:

critique task start "Prevent duplicate charges when an invoice retry races" \
  --agent claude-code \
  --accept "A retry cannot create a second charge" \
  --constraint "Preserve the existing webhook response shape"

The task ledger stores the request, acceptance criteria, constraints, explicit checkpoints, questions, and Critique responses. It is integrity-bound and restartable. The review projection contains the task contract and current repository state, but excludes the author's claims, transcript, plan, worklog, confidence, and conclusions.

That separation is the bias boundary: the author can explain what it intended to do, while the reviewer decides what the repository actually proves.

3. Ask while work is in motion

The second brain is collaborative. It does not take over the task or make the main agent wait for a final review.

critique ask "Which failure should we test first?" --session billing
critique ask "Compare a transactional outbox with an idempotency key" --session billing
critique chat --session billing

It can read and search the repository, run bounded diagnostics through Critique's evidence tool, and delegate read-only investigation. It cannot edit the author's tree. The named session persists across calls, so the main agent can ask, implement, checkpoint, and ask again.

Use ask when an independent perspective can change the next decision. Use review or finish when the answer needs executable proof.

4. Review the complete change

# Fast capsule-only orientation
critique quick

# Normal independent review
critique review "Check the retry implementation against its callers and tests"

# Review with a bounded repair package
critique finish \
  --intent "Prevent duplicate charges when an invoice retry races" \
  --repair pack \
  --json

The default base is HEAD. Critique includes staged and unstaged tracked changes, deletions and renames, and bounded safe untracked text files. It then materializes the candidate in a disposable workspace and gives the reviewer the complete repository, not only the diff. The diff locates the change; it does not define the review scope.

The reviewer performs deep repository reconnaissance through callers, tests, schemas, configuration, deployment, and operational paths. It selects relevant bundled methodologies, runs isolated specialist lanes when useful, and sends lane output to a fresh lead reviewer for adjudication.

5. Understand the bundled methodologies

critique skills
critique skills --json

Critique ships 38 substantive review methodologies in the published CLI. Each includes an investigation method, required evidence, and a disconfirmation path. The selected methodologies are injected into the reviewer runtime and executed as instructions. They are not a marketing count and are not reported as completed checks unless the reviewer actually performs them.

Customize selection and execution behavior in .critique/profile.json:

{
  "schema_version": "critique.review-profile.v1",
  "methodologies": {
    "include": ["concurrency"],
    "exclude": ["docs-contracts"]
  },
  "reviewer": {
    "repository_recon": "deep",
    "max_findings": 8,
    "require_reproduction": true,
    "verifier_model": "qwen/qwen3.7-flash"
  },
  "collaboration": {
    "style": "challenging",
    "interrupt_on": ["test_failure", "public_contract", "completion_intent"]
  }
}

The profile is portable, so a future configuration UI can export it without becoming part of the reviewer trust boundary.

6. Focus a review

critique cyber --intent "Probe the new authentication flow for reachable attack paths"
critique break --intent "Break retry and interruption behavior in the upload flow"
critique stress --intent "Stress the changed queue state machine"
critique security --intent "Threat-model and test the new auth flow"
critique performance --intent "Measure the changed search hot path"
critique reliability --intent "Test retries and recovery for this worker"

Focused commands select dedicated methodologies and can prepare a repair. They never commit, push, merge, deploy, or broaden the task without an explicit user decision.

7. Repair and verify

# Review only
critique finish --intent "Verify PAY-42" --repair none

# Prepare a patch without changing the caller tree
critique finish --intent "Verify PAY-42" --repair pack

# Apply only after fresh independent verification
critique finish --intent "Verify PAY-42" --repair apply

Critique captures supporting commands through its bundled plugin. A repair can be applied only when the fresh verifier has a reset workspace, a fresh conversation, Critique-controlled successful evidence, and a different model family from the repairer. Otherwise the result remains repair_rejected or unverified and the caller tree is unchanged.

8. Consume structured output

Use --json for agents and CI:

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

The result includes stable finding IDs, changed_paths, selected review methodologies, evidence references, limitations, usage, verifier independence, and repair state. --events sends machine-readable progress to stderr while stdout remains one JSON result.

9. Choose local or cloud execution

Local is the default. Critique runs the pinned reviewer runtime on the developer's machine, inside disposable workspaces. Source, patches, and normal environment files remain local.

Use cloud when the point is a clean remote machine or the local project cannot run. Cloud receives a protected working-tree snapshot, and each critic, repairer, and verifier receives a fresh full-repository workspace:

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

Only explicitly selected test environment values are sent to cloud. A normal .env is never uploaded automatically.