Crit
← Back to Crit

Integrations

Connect Crit to your agent.

Drop one file into your project. Your agent writes a plan, launches Crit for review, and waits for your feedback before writing code. The same integration works for reviewing code changes after your agent writes them.

Add the /crit slash command. It launches Crit, reads your comments, and revises the output automatically.

Copy to .claude/commands/crit.md

.claude/commands/crit.md 
---
description: "Review code changes or a plan with crit inline comments"
allowed-tools: Bash(crit:*), Bash(command ls:*), Read, Edit, Glob
---

# Review with Crit

Review and revise code changes or a plan using `crit` for inline comment review.

## Step 1: Determine review mode

Choose what to review based on context:

1. **User argument** - if the user provided `$ARGUMENTS` (e.g., `/crit my-plan.md`), review that file
2. **Recent plan** - if no argument, check if a plan was written earlier in this conversation. If so, review that file with `crit <plan-file>`
3. **Branch review** - otherwise, run `crit` with no arguments. It auto-detects what to review: uncommitted changes, or all changes on the current branch vs the default branch. Works on clean branches too.

Don't ask for confirmation — just proceed with whichever mode applies.

## Step 2: Run crit for review

If a crit server is already running from earlier in this conversation, skip launching and run `crit go <port>` to trigger a new round instead. Then skip to Step 2b.

Otherwise, run `crit` **in the background** using `run_in_background: true`:

```bash
# For a specific file:
crit <plan-file>

# For git mode (no args):
crit
```

Note the port from crit's startup output.

### Step 2b: Listen for review completion

Run `crit listen <port>` **in the background** using `run_in_background: true`:

```bash
crit listen <port>
```

Tell the user: **"Crit is open in your browser. Leave inline comments, then click Finish Review."**

Wait for the `crit listen` background task to complete — do NOT ask the user to type anything.

**Fallback:** If `crit listen` fails immediately (e.g. old crit binary without listen support), tell the user: **"Type 'go' here when you're done."** and wait for their response instead.

## Step 3: Read the review output

When `crit listen` completes, read the `.crit.json` file in the repo root (or working directory) using the Read tool.

The file contains structured JSON with comments per file:

```json
{
  "files": {
    "plan.md": {
      "comments": [
        { "id": "c1", "start_line": 5, "end_line": 10, "body": "Clarify this step", "quote": "specific words", "resolved": false }
      ]
    }
  }
}
```

Identify all comments where `"resolved": false` or where the `resolved` field is missing (missing means unresolved). If a comment has a `"quote"` field, it contains the specific text the reviewer selected — focus your changes on the quoted text rather than the entire line range.

## Step 4: Address each review comment

For each unresolved comment:

1. Understand what the comment asks for (clarification, change, addition, removal)
2. If a comment contains a suggestion block, apply that specific change
3. Revise the **referenced file** to address the feedback - this could be the plan file or any code file from the git diff
4. Use the Edit tool to make targeted changes
5. Mark it resolved in `.crit.json`: set `"resolved": true`, optionally add `"resolution_note"` (what you did) and `"resolution_lines"` (where in the updated file, e.g. `"12-15"`)

Editing the plan file triggers Crit's live reload - the user sees changes in the browser immediately.

**If there are zero review comments**: inform the user no changes were requested and stop the background `crit` process.

## Step 5: Signal completion

After all comments are addressed, signal to crit that edits are done:

```bash
crit go <port>
```

The port is shown in crit's startup output (default: a random available port). This triggers a new review round in the browser with a diff of what changed.

## Step 6: Next round

After `crit go <port>` triggers a new round, immediately run `crit listen <port>` in the background again to wait for the next review.

Tell the user: **"Changes applied. Review the diff in your browser and click Finish Review when ready."**

Wait for `crit listen` to complete. If the user finishes with zero comments, the review is approved — stop the loop and proceed.

## Sharing

If the user asks for a URL, a link, to share the review, or to show a QR code, run:

```bash
crit share <file>
```

**Always relay the full output to the user** — copy the URL (and QR code if `--qr` was used) from the command output and include it directly in your response. Do not make them dig through tool output to find it.

To also show a QR code — **only in real terminal environments** with monospace font rendering (not mobile apps like Claude Code mobile, or web chat UIs where Unicode block characters won't render):

```bash
crit share --qr <file>
```

To remove a shared review:

```bash
crit unpublish
```

Skill (recommended)

.claude/skills/crit-cli/SKILL.md

CLAUDE.md 
---
name: crit-cli
description: Use when working with crit CLI commands, .crit.json files, addressing review comments, leaving inline code review comments, sharing reviews via crit share/unpublish, pushing reviews to GitHub PRs, or pulling PR comments locally. Covers crit comment, crit share, crit unpublish, crit pull, crit push, .crit.json format, and resolution workflow.
---

# Crit CLI Reference

> If a plan was just written and the user said `/crit` or `crit`, invoke the `/crit` command — do not use this reference skill. This skill covers CLI operations like `crit comment`, `crit pull/push`, and `crit share`.

## .crit.json Format

After a crit review session, comments are in `.crit.json`. Comments are grouped per file with `start_line`/`end_line` referencing the source:

```json
{
  "files": {
    "path/to/file.md": {
      "comments": [
        {
          "id": "c1",
          "start_line": 5,
          "end_line": 10,
          "body": "Comment text",
          "quote": "the specific words selected",
          "author": "User Name",
          "resolved": false,
          "resolution_note": "Addressed by extracting to helper",
          "resolution_lines": "12-15"
        }
      ]
    }
  }
}
```

### Reading comments

- Comments are grouped per file with `start_line`/`end_line` referencing source lines in that file
- `quote` (optional): the specific text the reviewer selected — narrows the comment's scope within the line range. When present, focus your changes on the quoted text rather than the entire line range
- `resolved`: `false` or **missing** — both mean unresolved. Only `true` means resolved.
- Address each unresolved comment by editing the relevant file at the referenced location

### Resolving comments

After addressing a comment, update it in `.crit.json`:
- Set `"resolved": true`
- Optionally set `"resolution_note"` — brief description of what was done
- Optionally set `"resolution_lines"` — line range in the updated file where the change was made (e.g. `"12-15"`)

## Leaving Comments with crit comment CLI

Use `crit comment` to add inline review comments to `.crit.json` programmatically — no browser needed:

```bash
# Single line comment
crit comment --author 'Claude' <path>:<line> '<body>'

# Multi-line comment (range)
crit comment --author 'Claude' <path>:<start>-<end> '<body>'
```

Examples:

```bash
crit comment --author 'Claude' src/auth.go:42 'Missing null check on user.session — will panic if session expired'
crit comment --author 'Claude' src/handler.go:15-28 'This error is swallowed silently'
```

Rules:
- **Always use `--author 'Claude'`** (or your agent name) so comments are attributed correctly
- **Always use single quotes** for the body — double quotes will break on backticks and special characters
- **Paths** are relative to the current working directory
- **Line numbers** reference the file as it exists on disk (1-indexed), not diff line numbers
- **Comments are appended** — calling `crit comment` multiple times adds to the list, never replaces
- **No setup needed** — `crit comment` creates `.crit.json` automatically if it doesn't exist
- **Do NOT run `crit go` after leaving comments** — that triggers a new review round. Only the `/crit` command flow uses `crit go`, and only after addressing (not leaving) comments

## GitHub PR Integration

```bash
crit pull [pr-number]              # Fetch PR review comments into .crit.json
crit push [--dry-run] [pr-number]  # Post .crit.json comments as a GitHub PR review
```

Requires `gh` CLI installed and authenticated. PR number is auto-detected from the current branch, or pass it explicitly.

## Sharing Reviews

If the user asks for a URL, a link, to share their review, or to show a QR code, use `crit share`:

```bash
crit share <file> [file...]   # Upload and print URL
crit share --qr <file>        # Also print QR code (terminal only)
crit unpublish                # Remove shared review
```

Examples:

```bash
crit share <file>                                # Share a single file
crit share <file1> <file2>                       # Share multiple files
crit share --share-url https://crit.md <file>  # Explicit share URL
```

Rules:
- **No server needed** — `crit share` reads files directly from disk
- **`--qr` is terminal-only** — only use when the user has a real terminal with monospace font rendering. Do not use in mobile apps (e.g. Claude Code mobile), web chat UIs, or any environment where Unicode block characters won't render correctly
- **Comments included** — if `.crit.json` exists, comments for the shared files are included automatically
- **Relay the output** — always copy the URL (and QR code if `--qr` was used) from the command output and include it directly in your response to the user. Do not make them dig through tool output
- **State persisted** — share URL and delete token are saved to `.crit.json`
- **Unpublish reads `.crit.json`** — uses the stored delete token to remove the review
View all integration files on GitHub →