How do I have a second model review docs updates in a monorepo before each commit?

Tares lets Codex review every commit Claude Code makes in your monorepo, docs updates included, and sends Claude back to amend when a finding blocks. You turn it on by marking a Claude Code session as a challenger session. Codex also critiques the plan first, and you can waive any finding you disagree with.

How it works

A challenger session pairs two models. Claude Code plans and writes the docs changes as usual. The Codex CLI runs on your laptop in the Claude Code hooks, so the review never waits on Tares and Tares never calls Codex.

• Plan critique. When you approve the plan and Claude leaves plan mode, the plugin hands 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 as context, and only [P1] counts as blocking. Even then Claude revises or tells you why it disagrees.
• Commit review. After every git commit, Codex reviews that one commit. A docs-only commit gets the same review as a code commit.
• Blocking findings. On [P1] or [P2], Claude is stopped and told to fold the fix into the same commit with git commit --amend. If the commit is already on a remote, Claude makes a new commit instead. The amended commit is reviewed again as the next round. The loop stops at 8 rounds per commit and 5 turn ends per session, and after that the findings arrive as context.
• Never blocking. [P3] findings, a Codex timeout, an error and an inconclusive review all let Claude carry on.

In a monorepo everything hangs off one repository. Review state, fix-loop counters, the review history and waivers live under that repo’s .git/. A finding waived while you touch one package’s docs stays waived on later rounds for that finding.

Set it up

1. Run Tares, with its MCP endpoint next to it, or use a Tares Cloud instance, which serves the endpoint itself.

   tares up
   tares mcp --transport streamable-http

2. Install the Tares plugin for Claude Code, version 0.2 or later. The install asks for the Tares URL and the MCP endpoint. On a secured instance it also asks for a read + ingest API key.

   /plugin marketplace add glassflow/tares
   /plugin install tares@tares

3. Install the Codex CLI and log in. Codex is billed to your OpenAI account.

   npm install -g @openai/codex
   codex login

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

5. Start Claude Code at the root of your monorepo, or in the package you are documenting. Say “make this a challenger session”, or type /tares:challenger. The first marked session creates the Challenger workflow project for you.

6. Ask for the docs update in plan mode and approve the plan. Expect 30 to 90 seconds before Claude’s first reply while Codex reads the plan.

7. Let Claude commit. Watch the findings and the amends. If you disagree with a blocking finding, type /tares:challenger-waive. It lists the blocking findings and waives one or all of them, and a challenge_waived event is shipped to Tares.

8. Type /exit when you are done. A Tares agent then writes a summary of the session.

The challenger workflow guide has the full walk-through. If you want a second model checking commits for a whole crew instead of one session, the crew setup in Get started asks about it the first time you bring the crew up.

What you get

• A critique of the plan before any docs are written, and a review of every commit afterwards.
• Blocking findings that Claude must fix and amend before moving on, so the commit that stays has passed Codex.
• A way out when Codex is wrong: waive one finding or all of them, and the waiver holds for that finding on later rounds.
• One thread per session on Tares with the Claude and Codex exchange. The Sessions list shows the repo and branch, the plan outcome, and a Findings (N) or Pass badge for each reviewed commit.
• A session summary with up to five Memory proposals. When you accept one, it is written as a decision keyed by the repo, and the next session in that repo gets it as context before your first prompt. Nothing reaches memory without your accept.
• Events you can filter on, such as challenge_plan, challenge_commit and challenge_waived. Their verdict label carries Codex’s own word.

When something else fits

• If you want Codex’s notes as advice only, set the plugin option challenger_mode to advise. Commits then never block.
• If a session should run unreviewed, type /tares:challenger off. A session that was never marked is streamed like any other, and nothing runs.
• Codex runs on your laptop in a read-only sandbox by default. If a review needs to run the project’s commands, set codex_sandbox to workspace-write or danger-full-access.

Related