--- name: ops-inbox description: "OPS on-demand: This skill should be used when the user asks to \"check inbox\", \"inbox zero\"…" argument-hint: '[channel: whatsapp|imessage|email|slack|telegram|discord|notion|all]' allowed-tools: - Bash - Read - Grep - Glob - Skill - Agent - AskUserQuestion - TeamCreate - SendMessage - TaskCreate - TaskUpdate - TaskList - CronCreate - CronList - mcp__gog__gmail_search - mcp__gog__gmail_read_thread - mcp__gog__gmail_send - mcp__gog__gmail_labels # Slack — multi-workspace inbox scan uses these MCP tools when a workspace's # token is bound to the Slack MCP in ~/.claude.json. Workspaces whose # token_env is NOT bound to the MCP are scanned via direct curl from Bash # (no MCP entry needed for those). - mcp__claude_ai_Slack__slack_search_public_and_private - mcp__claude_ai_Slack__slack_read_channel - mcp__claude_ai_Slack__slack_list_channels - mcp__claude_ai_Slack__channels_list # Telegram: user-auth MCP tools added when configured # Notion: MCP tools (claude.ai integration or self-hosted) - mcp__claude_ai_Notion__notion-search - mcp__claude_ai_Notion__notion-fetch - mcp__claude_ai_Notion__notion-get-comments - mcp__claude_ai_Notion__notion-create-comment - mcp__claude_ai_Notion__notion-update-page - mcp__claude_ai_Notion__notion-create-pages # WhatsApp — these are the SINGLE-ACCOUNT server names (see CLAUDE.md Rule 8). # allowed-tools entries are exact strings, so if you run one bridge per account # (`whatsapp-personal`, `whatsapp-work`, ...) these will NOT grant access to yours. # Add your own per-account entries alongside these, e.g. mcp__whatsapp-work__list_chats. - mcp__whatsapp__list_chats - mcp__whatsapp__list_messages - mcp__whatsapp__search_contacts - mcp__whatsapp__send_message - mcp__whatsapp__get_chat - mcp__whatsapp__get_message_context - mcp__whatsapp__archive_chat - mcp__whatsapp__resync_app_state # iMessage — official `imessage` plugin. chat_messages reads ~/Library/Messages/chat.db # (allowlist-scoped); reply sends via AppleScript to Messages.app. No bridge, no daemon. - mcp__plugin_imessage_imessage__chat_messages - mcp__plugin_imessage_imessage__reply effort: high maxTurns: 60 context: fork --- # OPS ► INBOX ZERO 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`). ## ⚠️ WHATSAPP TRANSPORT — MCP ONLY, NEVER `wacli` For **all** WhatsApp operations in this skill (list chats, read messages, search contacts, send replies, archive chats), use the `mcp__whatsapp__*` tool family backed by the whatsmeow (Go) whatsapp-bridge — upstream `lharries/whatsapp-mcp`. (Earlier docs misnamed this as "Baileys" — Baileys is the Node.js WhatsApp library; this bridge uses `go.mau.fi/whatsmeow`.) > **Server name.** `mcp__whatsapp__*` is the single-account default. Installs with more than one account > register one server per account (`whatsapp-personal`, `whatsapp-work`, ...) and have no plain > `mcp__whatsapp__*` at all. Resolve the real name from the available tools before the first call, and > when several accounts exist, scan each one separately and keep the results labelled by account. See > CLAUDE.md Rule 8. **NEVER call the legacy `wacli` CLI** (`wacli chats list`, `wacli messages list`, `wacli send`, `wacli doctor`, `wacli history backfill`, etc). The wacli store and keepalive daemon are deprecated for this skill. If you find yourself reaching for any `wacli ...` shell command, stop and use the MCP tool with the same intent: | Intent | ✅ Use this | ❌ Do NOT use | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------- | | List recent chats | `mcp__whatsapp__list_chats {sort_by: "last_active", limit: 25}` | `wacli chats list` | | Read full thread | `mcp__whatsapp__list_messages {chat_jid, limit: 20}` | `wacli messages list` | | Full-text search | `mcp__whatsapp__list_messages {query: "", limit: 20}` | `wacli messages search` | | Resolve a contact | `mcp__whatsapp__search_contacts {query: ""}` | `wacli contacts` | | Send a reply (after approval) | `mcp__whatsapp__send_message {recipient: "", message: ""}` | `wacli send` | | Health check | `ops-wa-accounts --list`, then `curl -s -o /dev/null -w "%{http_code}" "$WA_API/api/v1/status"` (401 is healthy when the route is Bearer-gated). Never `lsof :8080`, never `launchctl kickstart` unless policy says the bridge is local. | `wacli doctor` / `~/.wacli/.health` | | Trigger history backfill | `curl -fsS -X POST "$WA_API/api/backfill"` (resolve `$WA_API` first — see "WHICH NUMBER" below; claude-ops patch — runs per-chat against the 50 most-recent chats; bridge also auto-backfills 5s after every Connected event) | — | **Rationale:** the bridge exposes a typed MCP surface, returns consistent JSON shapes (`is_from_me`, `content`, `timestamp`, `sender`), supports FTS5 search natively, and avoids store-lock contention with the wacli keepalive daemon. Mixing the two surfaces caused inconsistent state in past sessions. **Sole exception:** the `~/.wacli/.health` file is still readable for legacy daemon-health surfacing in other skills, but no `wacli` command should be invoked from this skill. ## ⚠️ WHICH NUMBER — resolve the account before the first read or send **This box may run more than one WhatsApp account.** The bridge process may be local, or it may run on another host with this machine as a **client**. Clients dial a local reverse-proxy URL from policy (`api` / `bridge_port` in `$PREFS_PATH` `.channels.whatsapp`, written by `/ops:setup` step 3b; `$OPS_DATA_DIR/registry.json` `.whatsapp` is the same shape). They never dial a remote IP, never guess `:8080`, and never start a local LaunchAgent "to recover" when policy says the bridge is elsewhere. A 401 on `$WA_API/api/v1/status` is healthy when that route is Bearer-gated. **Resolve first, every run, before any read, archive, or send:** ```bash "$CLAUDE_PLUGIN_ROOT/bin/ops-wa-accounts" --list # every account: port, number, agent, api # Two agent-enabled accounts: scan EACH, labelled. Do not call --port (exits 3 on purpose). # For each agent_enabled account in the JSON: WA_API=$account.api ``` `ops-wa-accounts` reads local `whatsapp-bridge*` stores if present, then **overlays policy** from `$PREFS_PATH` (wins), then registry, then legacy `~/.config/whatsapp/agent-policy.json`. Policy `api` / `bridge_port` always wins over a leftover local store's launcher port. A client box with no `messages.db` is still resolved. It exits 3 rather than pick one account when more than one is agent-enabled — that is a loop, not a stop. **The rules:** 1. **Never hardcode a port, never use whichever port answers, never probe a remote IP.** Use each account's `api` from the resolver JSON. 2. **A number can be agent-disabled.** An account with `agent_enabled: false` is off-limits: do not scan it, do not archive it, do not send from it, do not pair or re-pair it. 3. **Two agent-enabled accounts is not ambiguous.** Scan each, keep results labelled by account, reply on the number the thread lives on. Stop and ask only when none are enabled, or when unpolicy'd bridges appear with no `api`. 4. **Reply on the number the thread lives on.** Cross-account replies are never an acceptable fallback. 5. **Rule 8 applies to the MCP surface too.** With several accounts the servers are named per account (`mcp__whatsapp-personal__*`, `mcp__whatsapp-work__*`) and a bare `mcp__whatsapp__*` may not exist. Match the registered name; do not assume. Hermes `wa status` / `wa thread` / `wa find` is a valid read path on a client box when MCP is down. **Why this section exists:** a full inbox run once followed this skill's hardcoded `127.0.0.1:8080` and sent every reply from the wrong number. Guessing a port, or treating a missing local `messages.db` as "WhatsApp down", repeats that class of failure. ## Runtime Context Default: fan out one read-only scanner per configured channel after the offline scan. Skip fan-out only in the trivial case (~1–3 candidates). Full freshness / Mac fallback / version-heal / watcher: `references/runtime.md`. Every run, in order: 0. **Rank by VIP first.** Load the `vip` skill and resolve the VIP set once (`/ops:vip list`). Tier-1 senders are read and answered before anything else, tier-2 next, everything else after. A VIP with an unanswered inbound is surfaced individually with thread context, never as a line in a digest. Before drafting to any person, load `relations` for their brief and open commitments. 1. Resolve the WhatsApp account (`ops-wa-accounts` — never hardcode a port). 2. Freshness: `~/bin/wa-inbox-fresh.sh` (blocking, bounded). Then `bin/ops-inbox-scan`. 3. `bin/ops-inbox-archive-set` report-only. Present KEEP vs ARCHIVE; `--apply` only after explicit OK. 4. Deep-read KEEP / NEEDS_REPLY. Fan out if volume (`references/fan-out.md`). 5. Stage drafts one at a time (Rule 6). Archive after a verified send. Channel processing, FULL-THREAD AWARENESS GATE, and per-channel recipes: `references/details.md`. ## Standing behavior: RUN WIDE — parallel subagents / agent-teams / workflow by DEFAULT Every `/ops:ops-inbox` run should be fast for the owner, whose time is spent only reviewing and approving — never waiting on serial reads. By default: - **Fan out the moment there is more than a trivial amount of work.** After the offline `ops-inbox-scan` first pass, push the per-thread deep-read / dedup / context-gathering / draft-writing into parallel background workers — `Workflow` fan-out (preferred) or an Agent-Teams read-only scanner per channel/thread-chunk. Do NOT deep-read dozens of threads serially in the main session. - **Do research, context-gathering, and draft-writing in the background while the owner works.** Kick off the readers/drafters; let them build full-thread arcs, cross-channel dedup, contact profiles, and staged draft text concurrently. Surface results as they land so the owner approves in a steady stream instead of after one big serial pass. - **Parallelism NEVER changes the safety model.** Workers are strictly READ-ONLY — they classify and return draft text only. Every outbound send stays in the main session, one draft → one `AskUserQuestion` → one approval → one send (Rule 6 + PER-DRAFT APPROVAL). - **Respect the box concurrency ceiling** (heartbeat `MAX_BUSY`) — queue extra work rather than exceeding it. ## Scan engine — offline script triages first, Workflow fan-out is the DEFAULT for deep per-thread work **Run `bin/ops-inbox-scan` FIRST. It is the primary scan engine.** It classifies the two heaviest channels — WhatsApp (direct read of the whatsmeow sqlite store) and Email (one `gog gmail search`) — deterministically, in-process, in well under a second, emitting compact JSON. No subagents, no MCP, near-zero tokens. ```bash "$CLAUDE_PLUGIN_ROOT/bin/ops-inbox-scan" --pretty # both channels "$CLAUDE_PLUGIN_ROOT/bin/ops-inbox-scan" --whatsapp-only # WA only "$CLAUDE_PLUGIN_ROOT/bin/ops-inbox-scan" --days 14 # wider window # target a specific WhatsApp account (both flags, or neither): "$CLAUDE_PLUGIN_ROOT/bin/ops-inbox-scan" \ --wa-store ~/.local/share/whatsapp-mcp/whatsapp-bridge-