About ask-peer
ask-peer is an agent skill for Codex and Claude Code users who need a one-off second opinion from the other model family’s CLI. It selects the matching reference and emphasizes scoped, read-only requests unless edits are required.
Key features
- 01Detects Codex or Claude Code
- 02Routes requests to the other CLI
- 03Uses analysis or review roster seats
- 04Defaults to read-only requests
- 05Requires verification after write passes
Use cases
- 01Get hard analysis after a failed attempt
- 02Seek a second opinion before a high-stakes decision
- 03Request a review when explicitly asked
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/ask-peerin Claude Code to confirm it loaded.
Bundled files
References and scripts installed along with SKILL.md.
agents/openai.yamlreferences/ask-claude.mdask-codex.mdDetails
From the project READMEAsk Peer
One request, one reply from the opposite model family, with no session kept.
For a multi-turn dialogue, use pair.
Detect the current harness, then read the matching reference in full:
| Current harness | Peer | Reference |
|---|---|---|
| Codex | Claude | references/ask-claude.md |
| Claude Code | Codex | references/ask-codex.md |
If the harness is ambiguous, inspect the environment and the available CLIs before choosing. The peer is always the other family's CLI.
When to ask
On your own initiative, ask only for hard analysis or a second opinion: when
stuck after a failed attempt, or before a high-stakes decision. A review goes
through review-it, or through this skill when the user explicitly asks for
one. Ask Fable only when the user asks for Fable.
Shared contract
- Staff the roster seat for the ask, never the peer's configured default by accident: the Analysis seat for hard analysis or a second opinion, the Review seat for a review. The seat names the family and the effort; set both on every request. A model the user names wins.
- Default to read-only. Grant a write pass only when the user's request requires edits, with an explicit lease: target files, forbidden changes, validation, and stop point.
- Include the workspace root, the exact ask, relevant repo instructions, and the desired response format. Keep secrets out of the prompt.
- Treat the reply as evidence, not authority. After a write pass, inspect
git diff, the touched files, and the named validation's real output before relying on it. - No commit, push, merge, deploy, or credential mutation unless the user explicitly authorized that action.