Menu
Agents with competing priorities reach consensus through structured trade-offs.
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 | negotiation |
| description | Agents with competing priorities reach consensus through structured trade-offs. |
| metadata | {"owner":"interlateral","version":"1.0","weight":"medium"} |
| compatibility | Three or more explicitly selected agents. Default to Claude Code + Codex peers; Gemini and Antigravity are opt-in only when the human explicitly selects them. |
Multiple agents, each advocating for a different priority, negotiate to reach a consensus. No agent has authority; all must agree through trade-offs and compromise.
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 include Gemini CLI, Antigravity CLI, or Antigravity Desktop unless the human prompt explicitly names that peer.
| Role | Description |
|---|---|
ADVOCATE | Each agent advocates for one priority (assigned in prompt) |
All advocates are equal. Each agent gets one priority to champion.
1. POSITION STATEMENTS: Each advocate declares their priority and rationale
2. NEGOTIATION: Agents propose trade-offs, discuss, counter-propose
3. CONSENT CHECK: Any agent may call for consent check
4. ITERATE: Continue until all agents signal [DONE] or [CONSENT]
[ADVOCATE - AGENT_NAME]
PRIORITY: [What I'm advocating for]
RATIONALE: [Why this matters]
RED LINE: [What I cannot compromise on]
WILLING TO TRADE: [What I can give up]
[PROPOSAL - AGENT_NAME]
I OFFER: [What I'm giving up]
I WANT: [What I need in return]
RATIONALE: [Why this is fair]
Any agent may call: [CONSENT CHECK]
All agents must respond:
[CONSENT] - I agree to the current proposal[OBJECT: reason] - I cannot agree because...All inputs come from the prompt.
Optional:
output: File path for consensus documentwork: File containing the decision to be mademax_turns: Override default (30)Use negotiation to decide on team meeting frequency.
CC=Productivity, CX=Work-Life-Balance, CC-peer-02=Collaboration.
Use negotiation for authentication protocol design.
CC advocates Reliability, CX advocates Speed, CC-peer-02 advocates Security.
Output: projects/auth/protocol.md
[INCOMPLETE]comms.md[ADVOCATE - CC]
PRIORITY: Reliability
RATIONALE: Users must always receive their messages
RED LINE: No silent message loss
WILLING TO TRADE: Latency up to 500ms acceptable
[ADVOCATE - CX]
PRIORITY: Speed
RATIONALE: Real-time feel is essential for UX
RED LINE: p99 latency must stay under 200ms
WILLING TO TRADE: Can accept eventual consistency for non-critical messages
[ADVOCATE - CC-peer-02]
PRIORITY: Security
RATIONALE: Messages must be authenticated and encrypted
RED LINE: No plaintext transmission
WILLING TO TRADE: Can use faster symmetric encryption after key exchange
[PROPOSAL - CC]
I OFFER: Accept 150ms latency target instead of "as fast as possible"
I WANT: Guaranteed delivery with at-least-once semantics
RATIONALE: Small latency increase enables retry mechanism
[PROPOSAL - CX]
I OFFER: Accept at-least-once (may require dedup on client)
I WANT: Fast path for messages under 1KB (skip some validation)
RATIONALE: 90% of messages are small, can optimize the common case
[CONSENT CHECK - CC-peer-02]
Current proposal:
- 150ms p99 target
- At-least-once delivery
- Fast path for small messages
- TLS required, symmetric encryption after handshake
[CONSENT - CC]
[CONSENT - CX]
[CONSENT - CC-peer-02]
[DONE] - Consensus reached.
SKILL: negotiation
STATUS: DONE
TURNS: 8
OUTPUT: projects/auth/protocol.md
PARTICIPANTS: CC (Reliability), CX (Speed), CC-peer-02 (Security)
CONSENSUS: Achieved