Quickstart

This walkthrough reviews one uncommitted change in an invented project, inkwell, a notes app. It assumes cross-review is installed and codex is logged in; see Install.

1. Make a change

Add a Markdown export to inkwell, with a test. Leave the changes uncommitted:

src/export/markdown.js: a new function, exportNoteToMarkdown.
test/export.test.js: a test that checks the heading and the body of an exported note.

Run the project’s tests before you ask for a review, so the reviewer sees the change in its final state.

2. Ask for a review

Ask the agent to review the change with review-impl. Say what the change should do, because the reviewer checks the change against the request.

Claude Code
Codex

/review-impl Check my uncommitted changes. The request: add Markdown export for a note, with a heading for the title and the body unchanged.

$review-impl Check my uncommitted changes. The request: add Markdown export for a note, with a heading for the title and the body unchanged.

The skill works out the review mode from git: uncommitted changes make it a working-tree review. You do not pick a mode, a model or an effort unless you want to. Without a choice, the reviewer uses the settings in Settings or its own defaults.

3. Follow round 1

The agent starts the review and waits for the reviewer. While it waits, it reports what the reviewer is doing, for example that it is reading src/export/markdown.js. The reviewer runs in the background, so a review can take several minutes.

The agent stops waiting when the round ends and acts on the result. You do not need to do anything until it reports.

4. Read the outcome

Each round ends with one of these results. The agent acts on it and reports to you.

Result	Meaning	What the agent does next
`respond`	The reviewer raised issues	Fixes the accepted ones, disputes the rest with evidence, and sends the next round
`done`	The reviewer approved, or the two sides reached a stalemate	Ends the session and reports the verdict; a stalemate is yours to decide
`ask_user`	The round ended without a verdict	Shows you the reviewer’s text and asks how to go on
`stopped`	An error, a stall or a timeout ended the round	Stops the session and reports the reason; see Troubleshooting

A round with issues looks like this. The numbers and names are invented:

### ISSUE-1: Title line is written twice
- Category: bug
- Severity: medium
- Location: `src/export/markdown.js:18-22`
- Problem: the heading is added twice when the note has an empty body.
- Evidence: `if (!body) lines.push(heading)` runs after `lines.push(heading)`.
- Why it matters: the exported file has two identical headings.
- Suggested fix: return after the first push, and add a test for an empty body.

### VERDICT
- Status: REVISE
- Reason: one defect in the empty-body path.

The agent fixes ISSUE-1, adds the test, and replies with what it fixed. The reviewer checks the fix in the next round. Issue numbers stay the same from round to round. Core concepts explains how issues, verdicts and disputes work.

5. Open the dashboard

The dashboard shows every session in the folder and the rounds of each one, with the issues and their state. Start it from the repository:

cross-review dashboard

The command prints a link and opens it in your browser. The page runs only on your machine. See Dashboard for its views and options.

Core concepts: sessions, rounds, issues and verdicts.
review-impl: the skill in full, including branch and commit reviews.
Plans: for larger work, plan first with loop-plan.