# review-impl

> Have a second model check your uncommitted changes, unpushed commits or branch against the plan, then fix the valid issues and rebut the rest until the reviewer approves.

`review-impl` checks an implementation against its target before you commit, push or merge. The reviewer model (Codex CLI by default) looks for what is missing, where the code deviates from the plan in a way that breaks the target, and real defects: logic, edge cases, concurrency, resources, data integrity, security and runtime errors. You then fix the valid issues, rebut the others with evidence, and repeat until the reviewer approves.

Unlike `review-plan`, this skill edits code. The reviewer never edits files.

## When to use it

- After writing code, before you commit.
- After committing, before you push.
- Before you merge a branch, including your own pull request.
- At a review checkpoint that a `loop-plan` plan names. See [loop-implement](https://cross-review.tlelabs.com/docs/skills/loop-implement/).

For a pull request written by someone else, use [review-pr](https://cross-review.tlelabs.com/docs/skills/review-pr/) instead. It reviews without changing code.

## Invoke it

**Claude Code**

```text
/review-impl
```

**Codex**

```text
$review-impl
```

Add what to check in plain words, for example `/review-impl check the invoice rounding change against plan phase 2`. Name the approved plan and phase when there is one.

## What it works out by itself

- **The mode.** It reads `git status --short` and `git rev-list @{u}..HEAD`:

  - `working-tree`: staged or unstaged changes exist. The diff is the uncommitted change.
  - `branch`: the working tree is clean and commits are compared with a base.

- **The base, in branch mode.** Unpushed commits are compared with `@{u}`. The last N commits are compared with `HEAD~N`, resolved once to a commit ID so the range does not move when fixes are committed. For your own pull request, the base is the target branch, and the title and description go in the request. It checks the base is a real commit. If the range would include the repository’s first commit, it asks you how to proceed, because the review would cover the whole project.

- **The plan and target.** It names the approved plan when there is one, and passes along your decisions from the conversation.

It needs a non-empty diff to review.

## Round by round

1. **Start.** It calls `review_begin` with the mode, the request and any session context, and waits with `review_wait`. The session is stored under `.cross-review/sessions/`.

2. **The reviewer checks the change.** It reads the diff and the callers of changed functions, may run tests and builds to check its claims, and returns numbered issues (`ISSUE-N`) with category, severity, location, evidence and a suggested fix, then a verdict.

3. **Classify each issue.** In this order of authority: your latest decision, the request and approved target, verified repository facts, the change, then the reviewer.

   - **ACCEPT**: a real defect, or a deviation that makes the target wrong. The root cause is fixed and verified. A regression test is added where the defect can be tested.
   - **DISPUTE**: the issue is a style preference, optional polish, unrelated cleanup, or a limit with no resource at risk. The skill cites the request, plan, code or test that shows it.
   - **plan-gap**: the approved plan itself causes a bug or a real risk, or a better option is outside the plan. It is put to you as a proposal and not applied on its own.
   - **USER DECISION**: the valid fix would change behavior, scope, an interface, persistence, compatibility, dependencies or architecture. The other fixes are done first, then each decision is asked one at a time.

4. **Fix and check.** Each accepted issue becomes a code change with the smallest scope. Before replying, the skill checks what depends on the changed code and other places with the same pattern, then reruns the affected checks. In branch mode, the fixes are committed as new commits. Reviewed commits are never amended, rebased or force-pushed unless you ask.

5. **Reply.** It calls `review_reply` with `FIXED_ITEMS` (`ISSUE-N: <title> — fixed in <file>:<line>`) and `DISPUTED_ITEMS` (each disputed issue with its evidence, or `None — all issues addressed`). The reviewer checks again. There is no round limit.

6. **Finish.** When the reviewer returns `APPROVE`, the review is done and `review_end` is called. A stalemate is shown to you with the deadlocked issues.

> **Note:**
>
> The fixes in working-tree mode are changes to your files. Commit them yourself when you are ready. The skill does not commit in that mode.

## What you can say in chat

| You say                            | Effect                                                         |
| ---------------------------------- | -------------------------------------------------------------- |
| “Skip this review”                 | The review stops and the record shows you skipped it           |
| “Accept it as approved”            | The result is recorded as approved by you, not by the reviewer |
| “Stop”                             | The session stops; you can resume it later                     |
| “Resume the review”                | A stopped session continues with the same reviewer thread      |
| “Use model X” or “effort high”     | The model or effort is used, and remembered for later rounds   |
| A decision on a USER DECISION item | The skill applies that decision only                           |

## Example

Project: inkwell. You changed the rounding in the invoice total and have not committed.

1. The skill detects `working-tree` mode, since the diff is uncommitted, and starts the review.
2. Round 1: the reviewer raises ISSUE-1, a half-cent case that rounds the wrong way for negative credits (high severity, with a test snippet as evidence). It raises ISSUE-2, a rename in the changelog that the plan did not ask for (low). The skill accepts ISSUE-1, adds a regression test, and fixes it. It disputes ISSUE-2 because the rename is a deliberate part of the change in the request.
3. Round 2: the reviewer accepts the dispute and approves.

Afterwards, the skill reports the rounds, the verdict, issues found, fixed and disputed, and any remaining risks. You commit the change.

For a branch before a merge, the same flow runs in `branch` mode with the base set to the target branch, and the fixes become new commits.

See also [review-plan](https://cross-review.tlelabs.com/docs/skills/review-plan/) for reviewing the plan before the code exists, and [review-pr](https://cross-review.tlelabs.com/docs/skills/review-pr/) for someone else’s pull request.