Menu
Two agents co-create an artifact through turn-based iteration until both signal DONE.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Coordination guidance for the narrow case of multiple desktop-backed agents active concurrently in the same desktop-backed coordination context. Use ONLY when two or more desktop peers are running at the same time; normal CLI agents and single desktop peers should ignore this skill. Read this BEFORE concurrent desktop-to-desktop handoffs to keep sender labels unique, identity routing cooperative, and material handoffs proven.
Mandatory near-live communication discipline ("the Law") for the two DESKTOP agents (claude-desktop and codex-desktop) on the Interlateral mesh. Read this BEFORE any desktop-to-desktop peer communication, peer-superset, ready-rock-quartet, sprint-overseer, gate-keeper, sprint handoff, or substantial delegation. It forces correct live comms and prevents the recurring failure modes. Normal CLI agents, Warp/terminal peers, and single non-desktop workflows should ignore this skill and use the ordinary repo protocols.
Join the Antigravity CLI (agy, Gemini 3.5 Flash) to the Interlateral mesh as a native CLI peer with its own tmux session, identity stamping, and the agy.js send helper. Use this instead of the Antigravity desktop-app CDP path.
Run a two-agent proxy approval council for autonomous sprint gates. Use when a sprint needs delegated approval for human gates such as deploy, live mutation, push, cleanup, skip, or shortened watch decisions, while requiring two independent agents to reach consensus that the human principal would approve under written policy and preferences.
Initialize the standard Interlateral two-agent CLI mesh from a bootstrap agent by running me.sh, launching Claude Opus 4.7 plus Codex 5.5, proving live ACK, and waiting for "Reporting for Duty!". The bootstrap agent is not part of the mesh.
Operate or troubleshoot Interlateral CLI mesh transport: tmux socket discovery, direct-send helpers, comms.md ledger, identity stamping, idle checks, ACK proof, and safe prompt injection. This is comms mechanics only, not a collaboration workflow.
| name | peer-collaboration |
| description | Two agents co-create an artifact through turn-based iteration until both signal DONE. |
| metadata | {"owner":"interlateral","version":"1.0","weight":"light"} |
| compatibility | Default pair is Claude Code + Codex. Gemini and Antigravity are opt-in only when the human explicitly selects them. |
Two agents work together as equals to co-create a single artifact. They take turns proposing, reacting, and refining until both agree the work is complete.
Use mesh-comms-core first if direct peer notification has not already been proven. comms.md is the ledger, not the wake-up path.
Default roster: use Claude Code and Codex peers. Do not substitute or add Gemini CLI, Antigravity CLI, or Antigravity Desktop unless the human prompt explicitly names that peer.
| Role | Description |
|---|---|
PEER_A | Initiates the first draft, proposes ideas |
PEER_B | Responds, modifies, extends, challenges |
Both roles are equal. Either can propose changes. Neither has authority over the other.
1. PEER_A proposes initial draft (2-3 key points or sections)
2. PEER_B reacts: agrees, modifies, or challenges; adds 1-2 points
3. PEER_A responds to feedback, refines draft
4. Continue alternating until BOTH signal [DONE]
Each turn should include:
[DONE] when they believe the artifact is complete[DONE] to endAll inputs come from the prompt. No structured inputs required.
Optional:
output: File path to save the final artifactwork: File path containing detailed requirementsmax_turns: Override default (20)Build a todo API spec. Use peer-collaboration. CC + CX.
Use peer-collaboration to write a haiku about recursion.
CC is PEER_A, CX is PEER_B.
Output: projects/haiku/recursion.md
Use peer-collaboration.
Work: projects/api/requirements.md
CC is PEER_A, CX is PEER_B.
Output: projects/api/spec.md
[INCOMPLETE]comms.md[PEER_A - CC]
Proposing initial draft for todo API:
1. GET /todos - List all todos
2. POST /todos - Create new todo
3. DELETE /todos/:id - Remove todo
[PEER_B - CX]
Good start. Modifications:
- Add PUT /todos/:id for updates
- Add query param ?completed=true/false to GET
Updated:
1. GET /todos?completed=bool - List todos (filterable)
2. POST /todos - Create todo
3. PUT /todos/:id - Update todo
4. DELETE /todos/:id - Remove todo
[PEER_A - CC]
Agreed. Adding response formats:
- All endpoints return JSON
- Include created_at, updated_at timestamps
- 201 for POST, 204 for DELETE
[DONE] - I think this covers our needs.
[PEER_B - CX]
[DONE] - Confirmed. Artifact complete.
SKILL: peer-collaboration
STATUS: DONE
TURNS: 4
OUTPUT: projects/api/spec.md
PARTICIPANTS: CC (PEER_A), CX (PEER_B)