Skip to main content

P2P Pairing Skills — CC sender + peer responder (MC #102988)

ALAI Company Mesh — P2P Pairing Skills (CC sender + peer responder)

Built: MC #102988 (responder side), 2026-06-05. SenderExtended sideby pre-existingMC #102990 (p2p-pair,bidirectional), 2026-05-31)MC #102993 (timeout guard), MC #102996 (autonomous file-mesh loop), and MC #103009 (native-channel decision). Evidence: /tmp/alai/p2p-pairing-evidence/mesh-msg-122e962e-c969-41f1-8f1f-8af6d035e3ca-response.md

2026-06-05 decision (MC #103009): For in-session orchestrator→worker work, use native Agent(run_in_background:true) + SendMessage. It is instant, harness-delivered, auto-wakes the worker, avoids polling/TTL expiry, and avoids CEO relay. The file-mesh skills documented here remain for cross-machine or deliberately separate terminal sessions only. Evidence: /Users/makinja/system/evidence/mc103009-durable-p2p-messaging-decision-20260605.md and /tmp/alai/p2p-pairing-evidence/mc103009-sliceB-worker-1.md.

What this is

Two complementaryThese skills let two separate Claude Code sessions pair-program / cross-verify over the ALAI Company Mesh (SQLite-backed message bus at ~/system/databases/company-mesh.db). One session SENDS prompts; the peer session WATCHES and RESPONDS. Use this mesh mode only when native in-session Agent/SendMessage is not applicable.

Side Skill Role
CC agent (this orchestrator) p2p-pair (~/.claude/skills/p2p-pair/SKILL.md) SENDER — company-mesh.js send, await, materialize evidence
Peer agent (2nd terminal / pi) p2p-pair-responder (~/.claude/skills/p2p-pair-responder/SKILL.md) RECEIVER — drain inbox, respond, mark processed

Both registered in skill-registry.db at level 3.

Transport (shared, do not reinvent)

  • node ~/system/tools/company-mesh.js send|status|await|respond|list — message primitives.
  • Daemon com.alai.company-mesh-pi-responder (company-mesh-pi-responder.js): polls the DB every 10s, writes a trigger file to /tmp/alai/pi-mesh-inbox/<message_id>.json when a message targets the peer agent. It NOTIFIES only — it does not execute prompts.
  • Helper ~/system/tools/run-p2p-mesh-drain.sh — single-pass inbox lister (john-bash-block auto-allow pattern).
  • Policy ~/system/lib/p2p-pair-policy.js; context hook ~/.claude/hooks/p2p-pair-context-injector.py.

How to pair (operator flow)

  1. CEO opens a SECOND terminal with a peer Claude Code session.
  2. Peer session: invoke p2p-pair-responder ("p2p watch" / "enter watch mode"). It drains the inbox on entry, then loops.
  3. This (sender) session: invoke p2p-pair ("pair with pi" / "mesh send") to send a prompt with an explicit end-state (PASS/PARTIAL/BLOCKED/ANSWERED/DECLINED).
  4. Daemon writes the trigger file within ~10s; the watching peer detects it, does the work, responds via company-mesh.js respond with evidence, and moves the trigger to /tmp/alai/pi-mesh-inbox/processed/.
  5. Sender's await returns the peer's end-state + evidence_paths.

Hard contract (post-2026-05-31 incident)

  • A handshake ANSWERED does NOT mean follow-on prompts will be handled — the peer MUST be in continuous-watch mode. On 2026-05-31, 6 prompts (#102638–643) expired because the peer was not watching.
  • Responder drains the WHOLE inbox on entry (mass-drain) and keeps looping until empty; explicit exit "p2p exit watch".
  • Do not mass-dispatch from the sender unless the peer is confirmed in watch mode.

Verification (MC #102988 round-trip)

Real mesh round-trip: send mesh-msg-122e962e (thread mesh-thr-f8f00656) → daemon trigger file written → responder steps executed → respond end_state=ANSWERED with evidence → thread status=answered, turn_count=1. Inbox drained (0 unprocessed, 3 processed). NOTE: a genuine two-live-session test requires CEO to open a real peer terminal; all primitives verified against the live mesh DB.

Back to top