Menu
Review code changes, a plan, a live page (running dev server), or a local HTML file with crit inline comments
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use whenever creating or managing git worktrees.
Control Herdr from inside it. Use when running inside Herdr (`HERDR_ENV=1`) to inspect workspaces, tabs, panes, sibling agents, run commands in panes, read output, or wait for state changes via the `herdr` CLI.
use when leaving an automated comment on a GitHub PR or issue
Use when debugging, investigating root causes, ambiguous failures, predictions, risk/confidence estimates, or recommendations under uncertainty. Triggers are debug, troubleshoot, root cause, likely, confidence, predict, path forward, next step.
Use when an agent needs to author or reply to crit inline comments programmatically (including multi-agent workflows commenting on shared code/plans/docs/proposals), publish or unpublish a crit review with crit share, sync a crit review to or from a GitHub PR, or read/interpret a crit review JSON file. Covers crit comment, crit share, crit unpublish, crit pull, crit push, review file format, and resolution workflow. Not for invoking an interactive review loop — that's the `/crit` command.
User guide for the local squash-safe `stack` CLI for stacked PR/MR repair on GitHub and GitLab. Use when someone asks how to inspect, track, sync, merge, document, or undo stacked pull requests / merge requests in squash-merge repositories. Prefer this tool over GitHub's `gh stack` command for this workflow.
| name | crit |
| description | Review code changes, a plan, a live page (running dev server), or a local HTML file with crit inline comments |
| allowed-tools | Bash(crit:*), Bash(command ls:*), Read, Edit, Glob |
| argument-hint | [file|url] |
Review and revise code changes, plans, live pages (running dev servers, staging URLs), or local HTML files using crit for inline comment review.
critThe CLI auto-detects the review mode from its arguments. Do not ask the user which mode to use. Pass $ARGUMENTS through:
crit $ARGUMENTS # file, dir, URL, .html — CLI auto-detects mode
crit --pr <num|url> # GitHub PR (range mode)
crit --range <base>..<head> # commit range (range mode)
crit # no args → branch diff
If no arguments, check conversation context:
crit <plan-file>crit (branch diff)CRITICAL — you MUST run this step. Do NOT skip it. Do NOT proceed without it.
Run crit in the background using run_in_background: true:
crit <plan-file> # specific file
crit # git mode
If a crit server is already running from earlier in this conversation, crit automatically connects to it. Starting from scratch, it spawns the daemon, opens the browser, and blocks until the user clicks "Finish Review".
crit prints the review URL on startup (e.g. Started crit daemon at http://localhost:<port>). Relay it verbatim:
"Crit is open at http://localhost:. Leave inline comments, then click Finish Review."
Do NOT proceed until crit completes. Do NOT ask the user to type anything. Do NOT read the review file early. Wait for the background task to finish — that is how you know the human is done reviewing.
When crit completes, its stdout includes the path to the review file (e.g. "Review comments are in /path/to/review.json"). Read it.
The file contains structured JSON. Three comment types:
review_comments (top-level, r_-prefixed IDs) — general feedbackcomments array, no start_line/end_line) — about the file as a wholecomments array, with start_line/end_line) — about specific linesIdentify all comments where resolved is false or missing. Unresolved comments may have replies — read them before acting.
For each unresolved comment:
crit comment --reply-to <id> --author 'Claude Code' '<what you did>' (reply bodies support markdown)--resolve. Resolving is the reviewer's call. Only add --resolve if the user explicitly asks.Editing the plan file triggers Crit's live reload — the user sees changes in the browser immediately.
Use `--json` for a single bulk call instead of one invocation per comment:echo '[
{"reply_to": "c_a1b2c3", "body": "Fixed"},
{"reply_to": "c_d4e5f6", "body": "Refactored as suggested"}
]' | crit comment --json --author 'Claude Code'
If there are zero review comments: inform the user no changes were requested and stop the background crit process.
CRITICAL — you MUST run this step. Do NOT skip it. Do NOT proceed without it.
Run the exact same crit command from Step 2 in the background. The daemon is keyed by arguments — mismatched args spawn a new daemon instead of reconnecting. If Step 2 was crit plan.md, this must also be crit plan.md (not bare crit).
On subsequent calls, crit automatically signals round-complete first, then blocks until the next "Finish Review" click.
Tell the user: "Changes applied. Review the diff in your browser and click Finish Review when ready."
Do NOT proceed until crit completes. When it does, return to Step 3. If the user finishes with zero comments, the review is approved — stop the loop and proceed.
crit share <file>
Always relay the full output to the user — copy the URL (and QR code if --qr was used) directly into your response. Don't make them dig through tool output.
To remove a shared review:
crit unpublish
crit share --qr <file>