review-think

review-think is a peer debate on a technical question. You and the reviewer model (Codex CLI by default) each analyze the question on your own, then compare the results, challenge each other and converge. The result is a recommendation with its evidence, the points you both agree on, and any disagreement stated plainly.

This is reasoning, not code review. Both sides may read code, run commands, check documentation and search the web to test a claim. The reviewer must not change project files.

When to use it

• A decision or trade-off: architecture, a technology choice, a design, an approach.
• An investigation: why something fails, how a system behaves, whether a design holds, what a change would break.
• Any reasoning you want challenged before you act on it.

Do not use it for a written plan (review-plan), uncommitted or committed changes (review-impl), or someone else’s pull request (review-pr). If the request is one of those, the skill says so and suggests the right one, unless you want a debate anyway.

Invoke it

Claude Code

/review-think should the search index in atlas-notes be rebuilt on every start or updated as notes change?

Codex

$review-think should the search index in atlas-notes be rebuilt on every start or updated as notes change?

What it works out by itself

• The question. It turns your request into a question with a clear decision or target, the context it depends on (stack, constraints, what was already tried), and what a useful answer looks like. It shows the result as Sharpened question: "…" at the start. It does not ask you to confirm the rewrite; it asks only when the target cannot be inferred at all.
• The context. It takes the project context, relevant files and constraints from the conversation and the repository. Where a signal is ambiguous, it lists the options instead of picking one.

Round by round

1. Start. It calls review_begin with the question, the project context, the relevant files and the constraints.
2. Analyze alone. Before it reads any reviewer output, it works through the returned analysis_prompt and writes its own analysis to analysis.md in the session folder. The analysis has a position, key insights, considerations, recommendations, sources, open questions, a confidence level and a suggested status.
3. Wait and compare. It calls review_wait. When the reviewer’s answer is ready (next: cross_check), it compares the two analyses: where they agree, where they disagree, what only one side raised, and where the direction is the same but the depth or severity differs. Disputed claims are checked against sources or the code.
4. Decide the next step.
   • Exit rule met: review_end with outcome: "consensus".
   • The same disagreements remain, with no new evidence: review_end with outcome: "stalemate".
   • Otherwise: review_reply with the points you agree on, the points you disagree on (with evidence), and any new perspectives. Then it waits again.
5. Stalemate from the runner. When next is done, the reviewer or the runner has found a stalemate. The skill ends the session with outcome: "stalemate" and presents the deadlocked points with its recommendation.

A point that one side drops without new evidence or argument is not agreement. It is restated as a disagreement. The skill concedes a point only for a piece of evidence or an argument it had not weighed, and it names that point.

The report

The answer comes first:

• the recommendation for your situation, with the confidence level and why
• the consensus points
• the remaining disagreements, as a table with the point, the skill’s view and the reviewer’s view
• positions either side changed, and the evidence that changed them
• open questions
• consolidated sources

The same report is written to summary.md in the session folder. On a stalemate, the skill recommends which side to favor and asks you to decide.

What you can say in chat

You say	Effect
“Use model X” or “effort high”	The model or effort is passed to the reviewer, and remembered for later rounds
“Skip the debate”	The debate stops and the record shows you skipped it
“Stop”	The session stops; you can resume it later
“Accept the recommendation”	The recommendation is recorded as your decision, not as the reviewer’s

Example

Project: atlas-notes. The question is whether the search index should be rebuilt on every start or updated as notes change.

• Round 1: the skill’s analysis recommends incremental updates, citing the notes store code that writes each change. The reviewer recommends a rebuild on start for the current note count, and cites a timing test in the repository that it ran. The next step is cross_check.
• Round 2: both sides agree that a full rebuild is fast at the current size. The skill concedes that point, with the timing test as the reason. They still disagree on what happens at ten times the size, since neither has a measurement for it.
• Stalemate: the same disagreement repeats with no new evidence, so the skill presents both positions. It recommends incremental updates and asks you whether a larger note count is expected.

See Overview for how the skills fit together.