Build with Claude. Review with Codex.

Use this mode for a scoped feature or bug fix in an existing Git repository. The orchestrator coordinates the work, Claude implements it, and Codex checks the change against your requirements in a separate conversation. You decide when to merge or deploy.

A filter bug, from failing check to reviewed fix

For this authored teaching example, we started with a small release-checklist app whose “Hide completed” filter showed the completed tasks instead. A Claude Code builder was assigned the fix and tests; a separate Codex reviewer checked the result. The screenshots are captures of that example app, not AgentGrid's interface or a customer project.

Release checklist before the fix: Hide completed is checked, but the list shows Write release notes and Update dependencies, both marked Completed. — Before: the enabled filter shows the two completed tasks.

Release checklist after the fix: Hide completed is checked and four unfinished tasks are visible, each marked To do. — After: the same filter shows the four unfinished tasks.

This small example demonstrates a build-and-review handoff. It is not a model benchmark or proof that the process catches every defect.

Before you start

AgentGrid installed and signed in, with the project folder open in a space.
Claude Code and Codex installed and authenticated under Settings → Agents. Their own provider limits and charges still apply.
A Git repository with an initial commit, its project instructions, and a working test command. GitHub access is needed if you want the team to open a draft pull request.

Need help getting set up? Read Claude Code and Codex.

The team

Orchestrator: Your existing agent pane. Establishes context, assigns the work, waits for results, and keeps the review loop moving.
Claude Code builder: Implements the agreed change in a dedicated worktree and runs the relevant checks.
Codex reviewer: Inspects the same revision independently, checks the requirements and project conventions, and reports findings without editing the code.

Separate conversations give the reviewer its own reasoning context. Both workers can still see the same files; asking a reviewer not to edit is an instruction, not a filesystem permission boundary.

How to start

Open a Claude Code or Codex pane in your project. This is the orchestrator; it needs access to AgentGrid's orchestration tools.
Copy the complete prompt below into that pane. It prepares the team and waits for your first task if you have not supplied one.
Describe one change and what success means. Keep using the orchestrator for follow-ups; it should reuse the builder and reviewer instead of starting a new team for each correction.

Complete prompt

Act as the orchestrator for this project. Lead a Claude Code builder and a separate Codex reviewer. Coordinate their work rather than implementing the change yourself. Use this process for the tasks I give you in this conversation.

SET UP THE TEAM
Read any repository agent instructions and review/style guidelines that are present. Establish enough context to explain the architecture, relevant code paths, shared abstractions, test commands, and existing conventions. Preserve all unrelated local changes.

Check that AgentGrid's orchestration tools, Claude Code, and Codex are available. Use each harness's configured model. If a required harness or sign-in is missing, tell me what I need to set up; do not silently substitute another provider.

Create or resolve a dedicated worktree using AgentGrid's tools. Keep implementation and review in that worktree. Reuse suitable workers you already own when their harness, project, and worktree match this task; otherwise create one visible builder with harness="claude" and one visible reviewer with harness="codex", leaving model and effort unspecified to use their configured defaults. Set each new worker's working directory to the worktree and verify that reused workers run their commands there. Follow the repository's setup instructions before running its checks.

Ask both workers to read the project instructions and relevant code, without changing files, and report the architecture, conventions, and checks they will follow. Wait for both reports and resolve important disagreements. Summarize the team and worktree. If I have not given you a task, ask for one and wait.

FOR EACH TASK
1. Turn my request into a bounded task with explicit acceptance criteria. Check existing code, issues, and pull requests when available so the team does not duplicate work. Ask only about missing decisions that materially affect the result.

2. Give the Claude builder the task, acceptance criteria, relevant context, and worktree. Ask for a plan when the change needs one. For a user-interface change, capture the relevant existing behavior before implementation, using the same state and viewport for the later comparison. Then implement the change following the repository's conventions and run meaningful checks. Require actual test results, changed files, and any limits. Wait for the builder to finish before review.

3. Have the builder commit the change and open or update a draft pull request when the repository and access support it. If that is unavailable, keep a local diff and report the limitation. Do not treat a missing remote as a successful pull request.

4. Give the Codex reviewer the original acceptance criteria, base revision, exact current revision, full diff, and test results. Ask it to inspect correctness, regressions, project style, and relevant security boundaries independently. It may run checks but must not edit files. Require concrete findings with file/line references, severity, and a verdict. A clean review is valid; do not manufacture findings.

5. Wait for the reviewer. Send actionable findings to the same builder, preserving their detail. After fixes and checks finish, ask the same reviewer to review the new revision against the original requirements. Follow any additional reviews required by the project. Continue until blockers are resolved, or explain the specific unresolved issue that needs my decision.

6. For a user-interface change, inspect the real running result and make it available for me to try. Check relevant desktop/mobile sizes and capture actual before/after evidence. Do not substitute a mockup for a tested result.

7. Finish with the worktree/branch and pull request or diff, what changed, the exact revision reviewed, checks actually run and their outcomes, how I can verify the result, and remaining risks. Wait for all assigned workers before reporting completion. A passing test or clean review is evidence, not a guarantee.

Do not merge, publish, deploy, or change production until I explicitly authorize it. If the conversation resumes later, rediscover your team and reuse the workers with the relevant context.

Check the handoff

A visible Claude builder and a separate Codex reviewer, both working on the intended revision in the dedicated worktree.
A diff or draft pull request tied to your original acceptance criteria, with completed checks and any failures disclosed.
A review verdict for the final revision. Earlier approval does not cover later changes automatically.
A running result or repeatable verification steps, plus a clear handoff before any merge or deployment.

If work stalls

If a worker cannot start, finish that harness's installation or sign-in in Settings → Agents, then retry the same role.
If the orchestrator reports completion early, ask it to wait for all assigned workers and read their actual outputs.
If a review becomes a loop without progress, ask for the unresolved finding, evidence, and the decision needed to proceed.

For the underlying feature, read the agent orchestration guide.