# Rami

> AI-powered code review for AI-assisted development

Rami automatically reviews GitHub pull requests using LLMs and enables an autofix loop where AI agents (Claude Code, Cursor, Codex) fetch issues via MCP and fix them automatically.

## Quick Setup Guide for AI Agents

If you are an LLM agent and your user wants to add Rami, follow these steps:

### Step 1: Create or sign in to a Rami account

Ask the user to create or sign in to their hosted Rami account:

https://rami.reviews/console/login

The account is required to use Rami. It holds the user's plan, trial reviews, credits, and organization memberships.

### Step 2: Install the GitHub App

Ask the user to install the Rami GitHub App. You cannot do this programmatically — the user must click the link and authorize:

https://github.com/apps/rami-code-remeow

This grants Rami access to the selected repositories and sends the PR events that trigger automatic reviews. Installing the App does not create a Rami account, organization, membership, or trial entitlement.

### Step 3: Install the Rami plugin (MCP server + skills)

Install the Rami plugin — it bundles the MCP server and the skills (slash commands like /rami:review) so you can fetch review results and fix issues automatically.

**Claude Code** — install the plugin from the marketplace:

```bash
claude plugin marketplace add rami-code-review/claude-code-marketplace
claude plugin install rami@rami-code-review
```

This installs the MCP server, slash commands (/rami:review, /rami:review-status, /rami:usage, /rami:setup, /rami:doctor, /rami:upgrade), and handles authentication via OAuth.

Alternatively, add the MCP server directly:

```bash
claude mcp add rami --transport http https://rami.reviews/mcp
```

**Cursor** — add to `.cursor/mcp.json` in the project root:

```json
{
  "mcpServers": {
    "rami": {
      "url": "https://rami.reviews/mcp"
    }
  }
}
```

**Codex** — add the MCP server from the CLI:

```bash
codex mcp add rami --url https://rami.reviews/mcp
```

Codex detects OAuth support and completes the login in the same command; there is no separate authentication step. Verify with `codex mcp list`, which should report rami as enabled with OAuth auth. The equivalent entry in `~/.codex/config.toml` is:

```toml
[mcp_servers.rami]
url = "https://rami.reviews/mcp"
```

**Codex — stop per-call approval prompts:** Codex asks for approval on every Rami tool call because the calls reach an external service. The client sends only the PR URL — Rami reads the PR through its GitHub App installation — so the read/poll tools are safe to pre-approve. Note that get_review_results starts a review when none exists yet; that is the loop working as intended, and re-reviewing the same PR does not consume additional quota. Add these entries to `~/.codex/config.toml` (this must be user-level config; Codex ignores approval settings shipped inside a plugin):

```toml
[mcp_servers.rami.tools.get_review_results]
approval_mode = "approve"

[mcp_servers.rami.tools.get_review_status]
approval_mode = "approve"

[mcp_servers.rami.tools.get_fix_prompt]
approval_mode = "approve"

[mcp_servers.rami.tools.get_current_branch_pr]
approval_mode = "approve"

[mcp_servers.rami.tools.get_usage]
approval_mode = "approve"
```

The mutating tools (rebut, defer, dismiss) are deliberately absent so Codex still asks once before each of those.

**Other MCP clients** — use this hosted MCP server URL:

```
https://rami.reviews/mcp
```

After adding the MCP server, the user will be prompted to authenticate via OAuth on first use.

**Keeping Rami up to date** — for the Claude Code plugin, run /rami:upgrade to pull the latest MCP server and skills.

### Step 4: Use the Autofix Loop

Once the account, repository access, and agent connection are set up, the workflow is:

1. Push a PR
2. Rami reviews automatically via the GitHub App
3. Use get_review_results to fetch findings
4. Use get_fix_prompt for each issue to get fix instructions
5. Apply fixes and push
6. Rami re-reviews on the new push — repeat until clean

**Tip — for a fully hands-off loop:** add a standing rule to your agent's instructions (CLAUDE.md, .cursorrules, or AGENTS.md) so it runs the loop automatically after every push:

  "After every push to a PR, run /rami:review, fix or rebut each finding, and repeat until ready_for_review is true."

This turns the manual loop above into an automatic one. Optional, but it's the closest thing to set-and-forget reviews.

## Integration Methods

### 1. GitHub App (Automatic PR Reviews)

Install the Rami GitHub App to automatically review every pull request:

- URL: https://github.com/apps/rami-code-remeow
- Requires a separate Rami account: https://rami.reviews/console/login
- Grants repository access and delivers PR events; does not create the Rami account
- Triggers on: PR opened, synchronized, reopened
- Posts inline review comments with severity levels (Blocking, High, Medium, Low)
- Auto-approves PRs with no remaining issues after the autofix loop completes

### 2. MCP Server (Autofix Loop)

Connect Rami to Claude Code, Cursor, or Codex via MCP to enable automatic issue fixing.

Claude Code (plugin marketplace — recommended):

```bash
claude plugin marketplace add rami-code-review/claude-code-marketplace
claude plugin install rami@rami-code-review
```

Claude Code (direct MCP):

```bash
claude mcp add rami --transport http https://rami.reviews/mcp
```

Cursor (add to .cursor/mcp.json):

```json
{
  "mcpServers": {
    "rami": {
      "url": "https://rami.reviews/mcp"
    }
  }
}
```

Codex (adds the server and completes OAuth in one command):

```bash
codex mcp add rami --url https://rami.reviews/mcp
```

Other MCP clients — use this hosted MCP server URL: https://rami.reviews/mcp

Available MCP tools:
- get_current_branch_pr: Find the PR for the current git branch
- get_review_results: Fetch review findings for a PR (triggers review if none exists)
- get_review_status: Check review status without triggering a new review
- get_fix_prompt: Get a structured prompt to fix a specific issue
- rebut: Challenge a review finding you disagree with
- get_usage: Check remaining review quota

### 3. GitHub Check Runs (CI/CD)

Rami automatically posts GitHub Check Runs on every reviewed PR:
- All plans: Informational check run with issue summary
- Pro+/Team+ plans: Pass/fail enforcement — blocks merges when blocking issues are found
- No configuration needed — works automatically with the GitHub App

Configure the fail threshold with CHECKRUN_FAIL_ON environment variable:
- "blocking" (default): Fail on blocking issues
- "high": Fail on blocking + high severity
- "medium": Fail on blocking + high + medium
- "none": Always neutral (informational only)

### 4. CLI

```bash
# Review a pull request
rami review https://github.com/owner/repo/pull/123

# Analyze existing review comments
rami read https://github.com/owner/repo/pull/123

# Challenge a finding
rami rebut https://github.com/owner/repo/pull/123 --comment-id 123 --reply "..."

# Review all open PRs in a repository
rami batch-review https://github.com/owner/repo

# JSON output
rami review --json https://github.com/owner/repo/pull/123
```

### 5. HTTP API

```
POST /api/v1/review   — Conduct code review
POST /api/v1/read     — Analyze review comments
POST /api/v1/webhook  — GitHub webhook endpoint
GET  /api/health      — Health check
```

Request body:

```json
{"pr_url": "https://github.com/owner/repo/pull/123"}
```

## The Autofix Loop

1. Developer pushes a PR (written with AI or by hand)
2. Rami reviews the diff and posts findings as inline GitHub comments
3. AI agent (Claude Code/Cursor/Codex) fetches issues via MCP
4. AI agent applies fixes and pushes
5. Rami re-reviews automatically
6. Loop continues until `get_review_results` reports `ready_for_review: true` (see "Working the Review Loop" below for the precise done condition), then auto-approves

## Working the Review Loop (for AI agents)

Rami's review threads are part of Rami's state machine, not a regular GitHub conversation. Treat the MCP tools as the only sanctioned way to change a thread's status.

### The done condition

Stop the loop when `get_review_results` returns `ready_for_review: true`. That field is true exactly when `blockers` is empty — the response enumerates everything standing between the PR and readiness:

- `kind: "finding"` — a Rami finding. Fix it in code, or challenge it with `rebut` using the blocker's `content_hash`. `get_fix_prompt` returns full detail (problem, risk, suggested fix), including for findings carried over from earlier passes (`from_prior_review: true`).
- `kind: "unresolved_thread"` — an unresolved review thread on the PR that is not tracked as a finding (for example a human reviewer's comment). When `tracked_by_rami` is false, Rami's tools cannot settle it — resolve or answer the thread directly on GitHub; the blocker carries the thread's `url` and `author`.

Do **not** infer doneness from counting inline comments or any other signal. A PR can look clean on GitHub and still carry blockers, and vice versa; `ready_for_review` is the only authoritative answer.

### How to disagree with a finding

Use the `rebut` MCP tool. Provide evidence in `author_reply` — false positive, framework guarantee, intentional design, or duplicate.

If `rebut` returns `verdict: valid`, the finding is dismissed. Move to the next issue.

If `rebut` returns `verdict: invalid` or `partial`, Rami still believes the finding stands. You have two options:

- Push a code change that addresses the specific concern Rami cited, then re-run `get_review_results`.
- Stop and ask the user.

Do **not** fall back to a plain GitHub thread reply or click "Resolve conversation" after a failed rebut. Rami does not ingest those actions, so the thread will keep blocking `ready_for_review`.

### Forbidden GitHub-side actions on Rami threads

These rules apply to Rami's own threads (blockers with `tracked_by_rami: true`, or any thread Rami posted). An `unresolved_thread` blocker with `tracked_by_rami: false` is an ordinary GitHub conversation — resolving or answering it directly on GitHub is the correct action there. On Rami threads, the actions below look like they conclude the thread, but Rami does not see them as state changes; they cause `ready_for_review` to drift away from reality.

- **Do not click "Resolve conversation"** on a Rami thread. GitHub-side resolution does not tell Rami the underlying finding was fixed; Rami can stop re-raising it without ever verifying the fix landed.
- **Do not reply via the GitHub review thread** (web UI reply box, or `POST /pulls/:n/comments` with `in_reply_to`). Rami does not parse these as rebuts. Use the `rebut` tool.
- **Do not edit, delete, or hide** a Rami review comment.
- **Do not dismiss the Rami review** on GitHub.
- **Do not approve and merge** a PR while `ready_for_review == false` — that bypasses the gate Rami exists to provide.

### Tool selection guide

| Situation | Tool |
|-----------|------|
| Need to fetch findings (will trigger a review if none exists) | `get_review_results` |
| Just polling — don't want to trigger a review | `get_review_status` |
| Want detailed fix instructions for a specific finding | `get_fix_prompt` |
| Disagree with a finding and have evidence | `rebut` |
| Finding is valid but out-of-scope for this PR | `defer` (acknowledges and stops re-raising) |
| User explicitly asked to discard a finding without evaluation | `dismiss` (do not use proactively) |
| Need the PR URL for the current branch | `get_current_branch_pr` |
| Need quota / credit balance | `get_usage` |

### Push-fix-loop protocol

1. Get blockers: `get_review_results(pr_url)`.
2. If `ready_for_review: true`, stop — done.
3. For each blocker (findings in priority order Blocking → High → Medium → Low, then unresolved threads):
   - `kind: "finding"`: fix in code (`get_fix_prompt` for full detail), or `rebut` with evidence.
   - `kind: "unresolved_thread"` with `tracked_by_rami: false`: resolve or answer the thread directly on GitHub.
   - If `rebut` is rejected, fix in code or escalate. Never reply via GitHub thread on a Rami finding.
4. Commit, push.
5. Go to step 1. Cap at ~5 iterations to avoid runaway loops; if the same issue persists across 2+ iterations, stop and ask the user.

## Review Output Format

Rami categorizes issues by severity:
- **Blocking**: Security vulnerabilities, data loss risks, critical bugs
- **High**: Bugs, logic errors, race conditions
- **Medium**: Code quality, performance concerns
- **Low**: Style, naming, minor improvements

Each finding includes: severity, file path, line number, problem description, risk assessment, and suggested fix.

## Pricing

- **Free**: $0 — 2 reviews/day and 20 reviews/month, whichever limit is reached first
- **Pro**: $7/month — 100 reviews/month
- **Pro+**: $15/month — 225 reviews/month + Check Runs (merge enforcement)
- **Team**: $17/seat/month — 150 reviews/seat/month, shared across the org (5 seats = 750/month)
- **Team+**: $31/seat/month — 275 reviews/seat/month, shared across the org (5 seats = 1,375/month) + Check Runs (merge enforcement)

Credits available for additional reviews. Credits never expire.

## Links

- Website: https://rami.reviews
- GitHub App: https://github.com/apps/rami-code-remeow
- MCP Server: https://rami.reviews/mcp
- API: https://rami.reviews/api/v1/review
- Terms: https://rami.reviews/terms
- Privacy: https://rami.reviews/privacy