Two AI agents are better than one — especially when they disagree.
This skill teaches your agent to shell out to its peer for a second opinion. When Claude is working, it can consult Codex. When Codex is working, it can consult Claude.
Use it mid-task when you hit a design decision with meaningful trade-offs, or at the end to get a fresh set of eyes on the diff before the agent declares the work done.
The peer sees none of the original conversation, so the prompt has to stand alone — goal, relevant code, the constraint, a specific question. Terse one-liners get shallow answers back. Brief it like a smart colleague who just walked in.
The agent then synthesizes both perspectives for you — where they agree, where they disagree, and what it recommends after weighing both. Disagreements are the point: that’s where the useful signal lives.
Skill Prompt
---
name: cross-agent-review
description: Use when the user asks to "ask codex", "ask claude", "consult the other agent", "get a second opinion", or when you are about to declare a non-trivial change complete and want a peer agent to review the diff before handing back
---
# Cross-Agent Review
You have a peer agent available to consult. When you are running as Claude, your peer is Codex. When you are running as Codex, your peer is Claude. Use the peer as a second pair of eyes — either mid-conversation for a second opinion, or at the end to review a diff before declaring work complete.
## Protocol
Whichever direction you invoke, the protocol is the same:
1. **Summarize context in one self-contained prompt.** The peer does not see your conversation. Include only what it needs: relevant files, the constraint, options on the table, and the question or success criteria.
2. **Shell out to the peer.**
If you are Claude, call Codex:
```bash
codex exec -C YOUR-DIR "<context + question or diff + what to verify>"
```
If you are Codex, call Claude:
```bash
claude -p "<context + question or diff + what to verify>"
```
3. **Read the response carefully. Do not take it as ground truth** — treat it as one more perspective.
4. **Synthesize both perspectives for the user:** where you agree, where you disagree, and your own recommendation. If the peer surfaces something you missed, say so plainly. If the peer is wrong, say so and explain why.
## When to Use
### Second opinion (mid-conversation)
Trigger phrases: "ask codex", "what does codex think", "consult codex", "ask claude", "what does claude think", "consult claude", "get a second opinion", "check with the other agent", or an explicit request for an independent perspective on a design decision, architecture choice, or approach.
Use when a decision has meaningful trade-offs and a second perspective would de-risk it — not for every small question.
### Diff review (before declaring complete)
Trigger: you are about to declare a non-trivial change complete.
Pass the task description, the diff, and the success criteria. Apply any valid findings before handing back to the user.
## When NOT to Use
- Trivial questions with an obvious answer
- Fast-path edits where waiting on a peer burns more time than it saves
- Sensitive content you should not send outside the current agent (secrets, private discussion)
## Writing a Good Peer Prompt
The peer has zero context from your conversation. A good prompt stands alone:
- **State the goal** in one sentence.
- **Include the relevant code or diff** (paste it, or point to exact file paths and line numbers).
- **Name the constraint** that shapes the answer (perf budget, API contract, deadline, style rule).
- **Ask a specific question** or define success criteria. "Is this safe?" beats "Thoughts?"
- **Cap the response length** if you want something terse ("answer in under 200 words").
Terse one-liners get shallow answers. Brief it like a smart colleague who just walked in.