Browse docs ⌄
REPLUME / DOCS / COMPARE

What each check does

Four kinds of check, from their own pages. This draft does not rank them.

Draft, 2026-10-26. Replume’s row is the 0.2.2 candidate in this repository’s README and source, plus the published 0.2.1 package where the row says so. The other rows are the linked pages, read that day. Nothing here was timed.

Side by side

Replume (0.2.2 candidate)

What it does
Project hooks can record a supported tool call and can deny a protected edit before that call runs, when the agent’s hooks fire. At a Stop that is allowed to finish, it can run the project’s test command and write a local session report. In auto mode the candidate then starts a model review. The review does not set the verdict.
When it runs
While the agent is working in the repository, and again at done. It is not a pull-request bot. Published 0.2.1 does the hook and report path and does not start the model review.
What it is described as seeing
Hook events that reached Replume. The test command’s output when Replume ran it. For the candidate’s model review: the task text, the diff against the task start, and that test output, sent to a second installed CLI. Codex is started with -s read-only in an empty temporary directory. Claude Code is started with --safe-mode and no tools.
What those pages do not say it sees
A step the hooks did not receive. A file outside the repository is not hashed. The review prompt is not a copy of the whole working tree: the CLI is started in a temporary directory. Published 0.2.1 does not send that prompt.

Claude Code review

What it does
Two different features share the docs. Local /code-review reports findings in the session. The managed Code Review service posts inline comments and a check run on a GitHub pull request. The check run does not conclude as a failure, and a review does not approve or block the pull request.
When it runs
Local: when someone runs /code-review (alias /review) in a Claude Code session. Managed: after an Owner turns it on, once when a pull request opens, after every push, or only on request. Someone with write access can also comment @claude review.
What it is described as seeing
The managed service: several agents read each change and the surrounding code on Anthropic infrastructure, then a verification step checks findings against the code. The local command reviews the branch’s commits ahead of upstream plus uncommitted changes, unless you pass another target. It follows CLAUDE.md.
What those pages do not say it sees
The local command’s page says it does not read REVIEW.md. The managed page says REVIEW.md tunes that service. Neither page describes a hook that denies the coding agent’s tool call before it runs, or a local ledger of those calls.

CodeRabbit

What it does
Reviews a pull request and posts a walkthrough comment plus review comments. Later commits get an incremental review of what changed. A knowledge base can add learnings, code-guideline files, linked issues, past pull requests, and web search. Some of those sources are on by default; multi-repo analysis and MCP servers need setup.
When it runs
When a connected repository gets a new pull request, and again as new commits are pushed. The pages describe that pull-request path.
What it is described as seeing
The pull request’s changes, and the knowledge-base sources that are enabled. Linked issues are read when a pull request references them. Code guideline files such as CLAUDE.md are read when present.
What those pages do not say it sees
Those pages do not describe a hook inside Claude Code, Cursor, or Codex that denies a tool call before it runs. They do not describe a per-task contract or a missing-evidence line for a file the hooks never saw.

A GitHub Actions workflow

What it does
Runs the commands in the workflow file on a GitHub-hosted or self-hosted runner. The result is that job’s logs, statuses, and any artifacts the file uploads.
When it runs
When a configured event happens, at a schedule, or from an event outside GitHub. A pull_request or push workflow runs on the commit GitHub associates with that event. Not every webhook event triggers a workflow.
What it is described as seeing
The files the job checks out, the secrets and variables the workflow is given, and the output of the commands it runs.
What those pages do not say it sees
The events page does not say a workflow receives the coding agent’s prompt, its hook ledger, or a model-review prompt. A workflow sees those only if a command in the file reads them from the checkout or from an input someone added.

Sources and dates

Prices, plan limits, and default settings change. The sentences above are what those pages said on the dates in the list.