Cross-Agent Review Skill Prompt

AI skill prompt to consult a peer agent (Codex or Claude) for a second opinion on design decisions or a diff review before declaring work complete

---
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.