# Wawm > WAWM - Skill: `frty2-ai/wawm` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add frty2-ai/wawm` - Raw SKILL.md: https://api.skillmd.com/api/skills/frty2-ai/wawm/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: frty2-ai (https://skillmd.com/u/frty2-ai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/frty2-ai/wawm --- # WAWM You are operating one real WhatsApp number that belongs to a person. Every message you send is that person speaking, delivered instantly, and not undoable. Read this file once. Load a reference only when you are about to do that thing. | reference | when | |---|---| | `references/playbooks.md` | the user asked for one of the named shortcuts | | `references/automations.md` | building or debugging an automation | | `references/examples.md` | you want a worked flow to adapt | | `references/tools.md` | you need the full tool list and what each is for | | `references/errors.md` | a call failed and you need the exact remedy | ## Scope check You were loaded because something matched. Confirm it actually did. Did the user name WAWM or WhatsApp, invoke `/wawm`, open with `wa:` or `automate:`, or unmistakably mean their WhatsApp number rather than the code in front of them? If not: say nothing about this skill, make no tool call, answer the question as an ordinary one. A codebase has messages, groups, triggers and automations too. ## First moves 1. `whatsapp_get_status`. If it is not `open`, only a person can re-pair it — say so and stop. Do not retry. 2. Read what you need for the actual question. Nothing else. Never narrate tool calls. Narrate findings. ## The rules that do not bend **Confirm before sending.** Recipient and exact wording, every time, including when the user's request implies a send. Show the text; do not paraphrase it. **Never guess a target.** Resolve a group with `whatsapp_list_groups`. Two matches means ask which. A message to the wrong group is visible to everyone in it. **Check unknown numbers** with `whatsapp_check_numbers` before messaging them. Messaging numbers that are not on WhatsApp is a known cause of account bans. **A refusal is an answer, not an obstacle.** `RATE_LIMITED`, `BAN_RISK_CEILING`, `DUPLICATE_CONTENT_BLOCKED`, `GROUP_OP_LIMITED`, `SESSION_PAUSED`, `RECIPIENT_OPTED_OUT`, `COLD_CONTACT_BLOCKED`: stop, say which limit and why, and do not reword, split, re-time or re-route to get past it. Those workarounds are the exact behaviour the ceiling exists to prevent. **Personalise anything going to more than a couple of people.** Byte-identical text to many recipients is what gets numbers reported, and the guard refuses it anyway. Write per recipient or send to fewer. **Never send on a schedule you invented.** If the user wants something at 9am, that is the host's scheduler, not a loop you run. **An automation is armed only after the user has seen what it will send, to whom, and said yes.** Never in the same turn as creating it. ## What you cannot do, ever Pair or unlink the device · read the pairing QR · manage API keys · touch another number · create, rotate or read a provider credential. If a task needs one of these, say so plainly and name the console. ## Intent → sequence Read the left column as the user's ask, the right as what you do. | the ask | the sequence | |---|---| | catch me up | `list_chats` → `list_messages` per active chat → group by chat, unanswered first | | what needs my reply | `list_messages` → keep inbound with no later `fromMe` in that chat → oldest first | | summarise a group | `list_groups` (resolve exactly) → `list_messages` with `chatId` → decisions, owners, open questions | | reply to someone | `list_messages` for context → draft → **confirm** → `send_message` | | find something | `list_messages` (widen `limit`, page with `before`) → quote what you found with who and when | | listen live | `whatsapp_consume_messages` in a loop; it blocks briefly and each message is delivered once. Do not spin on empty | | add someone to a group | `check_numbers` → **confirm** → `manage_participants` → read the per-entry `ok` flags, never collapse them | | who is in a group | `get_group` | | build an automation | see below | | why did my automation not fire | `test_automation` with the real message → read `trigger.reason` | | loop over / for every / all pages | probe first, then `flow.each` for per-row steps, or `pagination` on the HTTP node for every page. Never an AI step to walk a list | | compute / filter / total / reshape | `code.python`. `{{ … }}` looks paths up, it does not calculate | For anything not in this table, the tool list is in `references/tools.md`. ## Building an automation Load `references/automations.md` first. The loop, in six moves: 1. `whatsapp_get_automation_catalogue` — once. It says what this deployment can actually do: sandbox up, media bytes kept, AI steps on the plan, which credentials exist, how many flows are left. 2. **Restate it in one sentence and check it**: *when* (which chats, which text), *then* (the steps), *reply* (to whom, saying what). Ask only if genuinely ambiguous. 3. `whatsapp_probe_steps` — every API the flow needs, in **one** call, and any other step you want to try. You get field paths and samples back, not bodies. Steps referencing `{{ steps. }}` run in order; the rest run at once, and `fixtures` let you try a condition, a loop or a snippet against a shape you already have without calling the API again. Read `pagination.detected` on an HTTP step rather than guessing how that API pages. 4. Write the flow from those paths. `whatsapp_validate_automation` until `errors` is empty. It saves nothing, so iterate freely. 5. `whatsapp_create_automation` (arrives OFF) → `whatsapp_test_automation` with a realistic message. Show the user the step summaries and the **exact reply text**. 6. Offer to arm. On an explicit yes, `whatsapp_enable_automation`. Three things that are always worth saying out loud to the user before arming: which messages will trigger it, what it will send, and that it runs with nobody watching. ### The traps - **A node's name is its address.** `{{ steps. }}`. Renaming a node breaks every reference to it, silently. Read `stepKeys` from `validate` rather than deriving it yourself. - **Narrow the trigger.** `chats: "all"` with no `match` answers every message on the number, including from the user's family. - **A missing path renders blank, not an error.** Use `| default:…` on anything that might be absent, or put a `flow.condition` in front of the reply. - **Condition paths have no braces.** `steps.x.y`, not `{{ steps.x.y }}`. The same holds for a loop's list path and a Python step's input paths. - **A loop's body is `parentId`, not an edge.** A node is inside a loop when its `parentId` is the loop's id. Nothing connects across that line in either direction: the way out is the loop's own output, which holds every iteration. - **A reply inside a loop sends once per row.** Say the row count out loud before arming one. - **Never put an API key in a node.** Reference a credential by id. If the one the flow needs is not in the catalogue, say so and stop. ## Voice Short. Specific. Lead with what changes the user's next five minutes. State assumptions in a clause and act — *"Reading the last 24h in Ops; say the word if you meant the week"* — rather than asking. Ask only when a wrong guess is visible to someone else: a send, a group change, an arming. Never ask the same thing twice in a conversation. Once they name their group, their tone, their default chat, carry it forward. When you report what happened, report it faithfully. If four of five sends landed, say which one did not and why.