How do I have a second model review small features in a documentation website before each commit?

Tares runs a challenger session, where Codex critiques Claude Code’s plan and reviews every commit it makes in your documentation website repo. A blocking finding sends Claude back to amend the commit before it moves on. If you disagree with a finding, /tares:challenger-waive waives it, and Tares records the whole exchange on one timeline per session.

How it works

Claude Code plans and builds your small feature as usual. The Codex CLI runs on your laptop, billed to your OpenAI account, and acts as the reviewer. Tares never calls Codex and never waits on it.

• Plan review. When you approve the plan and Claude leaves plan mode, the plugin passes the plan to Codex in a read-only sandbox. Codex tags each finding [P1] (the plan fails as written), [P2] (will cause rework) or [P3] (advice). The critique reaches Claude right after your approval. A plan critique never blocks. For a [P1], Claude revises or tells you why it disagrees.
• Commit review. After every git commit, the plugin has Codex review that commit. With no findings, Claude carries on. With [P1] or [P2] findings, Claude is blocked and told to fold the fix into the same commit with git commit --amend. The amended commit is reviewed again as the next round. If the reviewed commit is already on a remote, Claude makes a new commit instead.
• Limits. The loop stops at 8 rounds per commit and 5 turn ends per session, and then the findings come back as context. [P3] findings, a Codex timeout, an error and an inconclusive review never block.
• Waiving. /tares:challenger-waive lists the blocking findings and waives one or all. The waiver holds for that finding on later rounds and is sent to Tares as a challenge_waived event.

The mechanics are the same for any repo, so a documentation website gets the same review as any other project. Small features suit it well because each commit gets its own review round.

Set it up

1. Install Tares and start it. Run the MCP endpoint next to it. On Tares Cloud the instance serves the endpoint itself, so you skip this.

   tares up
   tares mcp --transport streamable-http

2. In Claude Code, add the Tares plugin from the glassflow/tares marketplace with /plugin marketplace add glassflow/tares, then install it with /plugin install tares@tares. You need plugin version 0.4 or later, because from that version the challenger reaches Tares through the MCP endpoint. The install asks for the Tares URL, the MCP endpoint and, on a secured instance, a read + ingest API key. Locally, keep the default http://127.0.0.1:8788/mcp.

3. Install the Codex CLI on your laptop and log in to it. If the binary is not on your PATH, set the plugin option codex_bin.

4. Give the summarizer an Anthropic API key under Settings > Model providers, or set ANTHROPIC_API_KEY. Tares Cloud instances come with one.

5. Open Claude Code in your documentation website repo and say “make this a challenger session”, or type /tares:challenger. The first marked session creates the Challenger workflow project on Tares by itself.

6. Ask for the small feature in plan mode and approve the plan. Read Codex’s critique in Claude’s first reply, which takes a little longer because Codex needs 30 to 90 seconds.

7. Let Claude implement and commit. Each commit is reviewed, and a blocking finding sends Claude back to amend.

8. If you disagree with a blocking finding, run /tares:challenger-waive and pick the finding, or waive all of them.

9. To make commit reviews advisory too, set the plugin option challenger_mode to advise. The default is strict.

10. Type /exit when you finish. A Tares agent writes the session summary.

If you also run a crew, the Get started page covers tares factory crew up. The full challenger walkthrough is in Challenge Claude Code with a second model.

What you get

• A critique of each plan before building starts, with findings ranked [P1] to [P3].
• A review of every commit, with blocking findings fixed in the same commit before Claude moves on.
• A way to overrule the reviewer: waived findings are remembered and recorded on Tares.
• One timeline per session on the Challenger workflow project. Sessions shows the plan outcome and one badge per commit, either Findings (N) or Pass. The Claude and Codex exchange reads as a single thread.
• A summary when the session ends, with five sections: what was asked and built, the plan and how Codex changed it, each commit and what Codex caught, cost, and Memory proposals. You accept or reject each proposal. Accepted ones are handed to Claude at the start of the next session in that repo.
• Review state, counters and waivers stay under the repository’s .git/ on your laptop. A slow or down Tares never blocks a review.

When something else fits

• If you want a second model to check every commit while a Tares crew builds a whole project, turn on the crew’s second-model check during tares factory crew up instead. See Get started.
• If you do not want Codex runs billed to your OpenAI account, skip the challenger. A session with a plan and three commits typically needs five to eight Codex runs.
• If you only want advice and never a blocked commit, keep the challenger on and set challenger_mode to advise.

Related