Integrations
Any agent that can run a shell command and read a file can use crit. All integrations follow the same pattern — only deviate when your agent has a specific quirk that requires it.
An integration is a set of skill files that teach your agent how to drive crit. Every integration ships two skills:
crit
The review loop
Launch crit, block until the user finishes reviewing, read the
review JSON, address comments, re-run crit for the next round.
This is the skill that powers /crit.
crit-cli
Headless CLI commands
Teaches the agent about crit comment, crit share, crit pull/push,
the review file format, and comment resolution workflow.
Auto-activates when the agent works with review files or crit commands.
Some agents need additional files — hooks, policies, commands, or plugins — but the two skills are the foundation. Keep them consistent with the existing integrations unless your agent genuinely requires something different.
This is the core protocol every integration teaches. Your agent repeats these steps until the reviewer approves with zero comments.
The agent runs
crit <file>
or bare
crit
for a branch diff. The CLI auto-detects the review mode. It spawns a daemon, opens the browser, and blocks until the user clicks Finish Review.
There is no separate listen or wait command — the crit process itself is the blocking gate.
When crit exits, it prints the path to a JSON review file. The agent
reads it and finds three types of comments: review-level
(r_-prefixed),
file-level, and line-level (with start_line/end_line).
Each comment may have a
quote
(selected text) and an
anchor
for locating content after edits.
For each unresolved comment, the agent makes the requested change, then replies:
For multiple replies, use
--json
for a single bulk call. The agent never passes
--resolve
— resolving is the reviewer's call.
The agent runs the exact same
crit
command from step 1. The daemon is keyed by arguments — mismatched args
spawn a new daemon instead of reconnecting. Crit signals round-complete,
reloads with a diff of what changed, and blocks again. Repeat from step 2.
Zero unresolved comments = approved. The agent stops the loop and proceeds with implementation.
All changes go in the crit repo. Here's what a PR looks like:
Copy from an existing simple integration (like
integrations/qwen/
or integrations/grok/)
and change the
--author
name. Keep the protocol identical — only adjust if your agent's
skill discovery format or execution model genuinely requires it.
cli_install.go
Add an entry to
integrationMap
mapping your agent name to file destinations:
source
(path in the embedded
integrations/
dir), dest
(project install path),
and optionally
globalDest
if your agent's global config lives somewhere different.
Run
go generate ./...
to update
integration_hashes_gen.go
(used by
crit check
for staleness detection). Update the snapshot test in integration_routing_test.go.
Add your agent to the table in
integrations/README.md
with install command, project path, and global path.
Most agents only need the two skill files. Some need more because of how they discover and load configuration. Only add extra files when your agent requires them:
Different global path
—
e.g. Pi uses
~/.pi/agent/skills/
for global installs vs
.pi/skills/
for project. Set
globalDest
in the routing table.
Custom commands or hooks
—
Gemini CLI needs a
.toml
command file, a policy file, and a settings merge for hooks. These
are unique to Gemini's plugin system.
Plugin registration
—
OpenCode needs a TypeScript plugin and a
opencode.jsonc
entry. Aider needs a
.aider.conf.yml
entry. These have custom install logic.
No global install —
Windsurf only supports a single shared global_rules.md,
so global install is rejected with a clear error.
If none of these apply, keep it simple: two skill files and standard routing.
Real PRs in order of complexity. Start with a simple one as your template.
Grok Build
Simple — two skill files, standard paths, no special config. Best starting template.
Qwen Code
Simple — same pattern as Grok. Good second reference.
Pi Coding Agent
Medium — different global path
(~/.pi/agent/skills/ vs project .pi/skills/).
Gemini CLI
Complex — skills + command file + policy + hook settings merge. Only needed because of Gemini's TOML-based plugin system.
Once your integration is merged,
crit install
copies the embedded skill files to the right place. Two modes:
Safe to re-run. Existing files are skipped unless
--force
is passed.
crit check
detects stale integrations by comparing installed file hashes against the
manifest baked into the binary.
All integration files live in the crit repo:
If your agent isn't supported yet or you run into issues building an integration, open an issue and we'll help you get it working.
Open an issue on GitHub