Ops Comms

OPS ► COMMS

Load ops-rules before acting. Public repo (no personal data). Outbound: one draft → one approval → one send. If AskUserQuestion / Workflow are missing, follow Rule 10 in ops-rules (Hermes: numbered options / two-turn Telegram card; delegate_task).

Runtime Context

Before executing, load available context:

1. Daemon health: Read ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/daemon-health.json

   • Check bridge liveness before any WhatsApp operation: lsof -i :8080 | grep LISTEN
   • If bridge not running, prompt user to restart: launchctl kickstart -k gui/$UID/com.${USER}.whatsapp-bridge

2. Ops memories: Before drafting any message, check ${CLAUDE_PLUGIN_DATA_DIR}/memories/:

   • contact_*.md — load profile for the recipient
   • preferences.md — match user's communication style, language, and tone
   • donts.md — restrictions that must not appear in any draft

3. Preferences: Read ${CLAUDE_PLUGIN_DATA_DIR}/preferences.json for default_channels to determine which channel to prefer when multiple are available for a contact.

Routing table

Natural-language parsing:

• send "deploy done" to #general on discord → bin/ops-discord send general "deploy done".
• call <contact> / dial <contact> / phone <contact> → resolve number, then bin/ops-voice phone <E.164>.
• facetime <contact> (with optional audio) → bin/ops-voice facetime <handle> [--audio].
• start a zoom / new zoom meeting → bin/ops-voice zoom start.
• join zoom <ID> → bin/ops-voice zoom join <ID>.
• text <contact> "<body>" / sms <contact> "<body>" → bin/ops-voice twilio-sms <to> $TWILIO_FROM_NUMBER "<body>" (guarded by per-message approval).

Send flow: send [message] to [contact]

1. Parse contact name and message from $ARGUMENTS.
2. Determine channel by contact lookup:
   • Check WhatsApp: mcp__whatsapp__search_contacts {query: "[contact]"} 2>/dev/null
   • Check Slack: mcp__claude_ai_Slack__slack_search_users with query: "[contact]"
   • Check email: known from context or ask
3. If multiple channels found, use AskUserQuestion: [WhatsApp] / [Slack] / [Email]
4. Always preview before sending. Use AskUserQuestion to confirm:

Ready to send via [channel]:
  To: [contact name] ([identifier])
  Message: "[full message text]"

  [Send now]  [Edit message]  [Cancel]

If user picks "Edit message", use AskUserQuestion with free-text to get the revised message, then re-preview.

5. Send via the chosen channel. Confirm with: Sent to [contact] via [channel] ✓

WhatsApp send

CRITICAL — READ BEFORE SENDING: Before drafting ANY WhatsApp reply, you MUST:

1. Read the full conversation: mcp__whatsapp__list_messages {chat_jid: "<JID>", limit: 20}
2. Understand which messages have is_from_me: true (user sent) vs is_from_me: false (contact sent)
3. Summarize what the conversation is about and what the contact is asking
4. Only THEN draft a reply that addresses what the contact actually said

Never send a reply based on a single message. A message like "can you pull it from Klaviyo?" means nothing without knowing what "it" refers to from prior messages.

Pre-flight: Check bridge is running: lsof -i :8080 | grep LISTEN. If not running, restart: launchctl kickstart -k gui/$(id -u)/com.${USER}.whatsapp-bridge and wait 5s.

mcp__whatsapp__send_message {recipient: "[contact_jid]", message: "[message]"}

Slack send

Use mcp__claude_ai_Slack__slack_send_message with resolved channel/user ID.

Email send (draft)

Use mcp__claude_ai_Gmail__create_draft — always create draft first. Then use AskUserQuestion:

Draft created for [recipient]:
  Subject: [subject]
  Body: [preview]

  [Send now]  [Keep as draft]  [Edit]

Outbound judgment: verify before you assert

Before drafting to a person, load relations for their brief, open commitments and the full-context draft order, and vip for their tier. A tier-1 recipient is drafted with extra care and never handled from a digest line. Neither skill can send; Rule 6 still owns the send.

Rule 6 governs whether a message may go out. This section governs whether the message is right. Every item below is a failure mode seen on a real run, where the approval gate held and the content was still wrong.

Research every load-bearing claim

Never state a fact in someone else's inbox from memory. A price, a date, an availability, a "who currently holds X" all get a cheap check first: a search, the actual thread, the calendar, the invoice.

Claims about the recipient's own access get probed, not inferred. Telling a colleague their access is broken is a claim about a system you can inspect. A wrong diagnosis sends a competent person chasing a non-problem, and they will believe you because you appear to hold the admin view. Sort each access item into fixed, never broken, or theirs, and say which. Telling someone "that already works" stops them building a workaround for a permission they already have.

Verify the join, not just the endpoints

The hardest fabrications are not invented facts, they are invented relationships between two real things that share a name, an entity, or a keyword. Each half is true, the sentence joining them is not, and it reads as diligence rather than a guess.

"X should be coordinated with Y" is itself a factual claim and needs its own evidence. A company or person appearing in two matters is weak evidence they are the same workstream and often strong evidence of a naming coincidence. Be especially suspicious of an advisory clause nobody asked for: the recipient asked a yes or no question, and a "let's just align with..." rider is exactly where invented linkage hides. When challenged on such a clause, probe and delete it rather than rewording it into something defensible.

Do not absorb the other party's job

An inbound message that mentions a task is not automatically a task for the user. When the sender owns the workstream, a heads-up about their own work in progress is not an instruction transferring that work.

Before staging any reply containing a first-person commitment ("I'll pick that up", "I'll clean that up"), check whose function it is, who has the access, and whether the commitment is even wanted. A message that only needs acknowledging gets acknowledgement. Volunteering labour reads as helpful and creates real obligations nobody tracks. When the work does need doing and the counterparty owns it, name it and hand it back rather than quietly taking it on.

Do not route a decision the counterparty already made

A narrow A/B to the user is right for a real trade-off and wrong when the counterparty already supplied the answer inside the message being triaged. An identifier a person gives for their own account (login, email, phone, handle, bank account) is authoritative. A conflict with the admin view means the estate is misconfigured, not that they misremembered their own account. Use the probing to shape the message, not to defer. Escalate only when the action is irreversible and expensive; two systems disagreeing is neither.

The tell that this rule was broken is a closing question to the user whose answer is already quoted verbatim in the inbound message.

A staged draft goes stale

A queue of drafts is researched at one moment and sent over hours. Any draft referencing a pending external process (a bank instruction, a signature, a shipment, a filing) must have that process re-checked immediately before the send, not just at research time. A draft that correctly said "still waiting, no news" became wrong when the counterparty's reply landed mid-queue.

Two consequences are easy to miss: the draft's central claim can flip outright, and new inbound often creates a second outbound that also needs drafting. Search results encountered mid-queue get triaged, not skimmed past.

A parallel session may have already sent it. Multiple agents can work the same inbox and send under the same identity. Treat any outbound from the user's own identity that this session did not write as another agent's work: verify its claims at the source, report the item closed with that evidence, and move on. Do not re-send, and do not assume it was correct just because it exists.

A counterparty's restatement of your position is not authoritative

When someone replies "which of these did you mean?" or summarises your position back before proceeding, do not pick the more plausible reading. Open what the user actually sent and read their own words. A partner who guesses wrong and proceeds on that guess can commit the user, in writing, to a different deal than the one they proposed. Their politeness is not evidence; a soft hedge from a competent counterparty is exactly where an unnoticed inversion lives.

When the user contradicts your draft, check before defending it

Low-confidence pushback ("check, I think we already signed", "I might have credentials too") is a hard stop and a research instruction, not a hedge to be reassured about. Re-probe the primary source and come back with what it says, including "partly, the mechanism is X not Y". Never defend a draft against the user's own recollection without checking first.

Do not trust an audit's verdict over primary evidence

A subagent audit is a research artifact, not a finding. Before acting on a cancel-or-delete verdict, open one paid invoice and read the SKU, quantity, billing address, and payment history. "No API key in the environment" does not mean "unused": no-code SaaS runs entirely in a web UI. A "paused" or free-tier notice may belong to an entirely different account than the paid plan.

Reply to their message, not your parallel checklist

When the user says "just reply", answer only the inbound ask. Do not bolt on extra forms, address updates, or multi-item checklists they did not ask for in that draft. Extra tracks get a separate message after the send if still needed. When the user corrects a draft to be shorter or more spoken, rewrite against their wording, not a re-packaged version of your own.

A work handover must match the tracker exactly

When a message tells someone what to work on, do not paraphrase the tracker. Re-run the query and enumerate every open item in board order with identifier, priority, and state. Vagueness is how items get silently dropped and how the recipient invents their own ordering. If something is deliberately excluded, say so and why rather than omitting it silently.