--- name: Ops Inbox Zero slug: ops-inbox-zero category: Automation description: Ops Inbox Zero handles WhatsApp inbox triage, reads threads, and drafts or sends replies after approval. Use it when asked to check inbox, clear messages, archive chats, or respond through the OPS workflow. github: "https://github.com/Lifecycle-Innovations-Limited/claude-ops/tree/main/claude-ops/skills/ops-inbox" language: Shell stars: 186 forks: 21 install: "npx degit https://github.com/Lifecycle-Innovations-Limited/claude-ops/tree/main/claude-ops/skills/ops-inbox ~/.claude/skills/ops-inbox" installs_to: ~/.claude/skills/ops-inbox source_path: claude-ops/skills/ops-inbox/SKILL.md collection_size: 25 category_size: 2032 collection_url: "https://dirskills.com/collections/Lifecycle-Innovations-Limited/claude-ops" added: 2026-09-06T05:20:39.183Z last_synced: 2026-09-06T05:20:39.183Z canonical_url: "https://dirskills.com/skills/ops-inbox-zero" --- # Ops Inbox Zero Ops Inbox Zero handles WhatsApp inbox triage, reads threads, and drafts or sends replies after approval. Use it when asked to check inbox, clear messages, archive chats, or respond through the OPS workflow. **Install:** ```bash npx degit https://github.com/Lifecycle-Innovations-Limited/claude-ops/tree/main/claude-ops/skills/ops-inbox ~/.claude/skills/ops-inbox ``` ## README # 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-nl`, `whatsapp-us`, `whatsapp-personal`, `whatsapp-work`, ...) > and have no plain `mcp__whatsapp__*` at all. `whatsapp-cos` is not an account — do not send on it. > 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 / ops-rules 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-nl__*`, `mcp__whatsapp-us__*`, or `whatsapp-personal` / `whatsapp-work`) and a bare `mcp__whatsapp__*` / `mcp__whatsapp-cos__*` is not an account. 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. **All-context sweep** (Rule 9 + `references/details.md` "ALL CONTEXT SOURCES"): query every configured calendar, mailbox, and messaging channel before any schedule claim or NEEDS_REPLY draft. Google Calendar alone is not enough — Notion show/calendar databases count when Notion is configured. A miss on one store is not absence. 4. `bin/ops-inbox-archive-set` report-only. Present KEEP vs ARCHIVE; `--apply` only after explicit OK. 5. Deep-read KEEP / NEEDS_REPLY. Fan out if volume (`references/fan-out.md`). 6. 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-