Chat Group Behavior

How to join, participate in, and leave group conversations on messaging platforms (WhatsApp, Signal, Telegram, etc.). Use when the owner tags the agent into...

Security Scan

The instructions largely match the stated purpose (managing group participation) but they require direct modification of agent config and session files and recommend widening message filters — actions that are not declared in the metadata and increase privacy/safety risk.

Purpose & Capability

The skill's purpose is 'chat group behavior' which legitimately requires changing agent behavior settings, but the SKILL.md instructs the agent to patch openclaw.json and sessions.json and to create cron jobs. The registry metadata declared no required config paths or credentials, yet the runtime instructions require read/write access to agent configuration and session files. This mismatch (undisclosed need to modify local config/session files) is a coherence problem.

Instruction Scope

Instructions explicitly tell the agent to: patch channels.<platform>.groups.<group_id>.requireMention in openclaw.json; set channels.<platform>.groupAllowFrom to ["*"]; create one-shot cron jobs to re-patch config later; and (in troubleshooting) clear session transcript files referenced from sessions.json. These are more than passive 'behavior guidelines' — they instruct file-system changes and deletion of session data. Widening groupAllowFrom to ["*"] and clearing session transcripts carry privacy and persistence implications beyond simple group participation.

Install Mechanism

This is an instruction-only skill with no install spec and no code files. That minimizes supply-chain risk — nothing is downloaded or installed by the skill itself.

Credentials

The skill declares no required environment variables or config paths, but the instructions require modifying openclaw.json and accessing session transcripts (sessions.json and session files). That is disproportionate to what's declared. Additionally, the recommendation to set groupAllowFrom to ["*"] increases the set of inbound messages delivered to the agent and may surface user content the owner did not intend the agent to receive.

Persistence & Privilege

always:false and normal invocation settings are fine. However, the skill instructs making persistent config changes (patching openclaw.json) and creating scheduled cron jobs. Those are persistent privileges affecting agent behavior and should be granted explicitly by the owner; they are not documented in the skill metadata.

What to consider before installing

Key things to consider before installing or using this skill: - The skill will (per its instructions) read and write your agent configuration (openclaw.json) and access or clear session transcript files (sessions.json references). The metadata does not list these config paths; ask the skill author to declare them. - The skill recommends setting channels.<platform>.groupAllowFrom to ["*"]. That widens which group members’ messages are delivered to the agent and may expose private or sensitive messages. Prefer making this change per-group and limited in time, or require explicit owner approval each time. - Confirm whether the patches are per-group or global. Global changes to groupAllowFrom or channel-wide settings can affect behavior for unrelated groups. - The skill creates one-shot cron jobs (scheduling). Ensure you trust the agent to create scheduled tasks and that you can audit or revoke them (and verify where cron jobs are stored/executed on your system). - The troubleshooting advice to delete/clear session transcript files can remove audit trails and/or sensitive data. Back up session files before any automatic clearing and require explicit owner consent. If you proceed: require the skill to (1) list exact config paths it will modify, (2) limit groupAllowFrom changes to the specific group and duration (not a global wildcard), (3) require owner confirmation before clearing session transcripts, and (4) provide a dry-run or preview of config changes plus an easy rollback. If the author cannot or will not provide these, treat the skill as higher risk and avoid granting it write access to config/session data.

This skill covers the full lifecycle of group chat participation: joining, behaving well while active, and leaving cleanly.

Prerequisites

channels.<platform>.groupPolicy, groupAllowFrom, and groups.*.requireMention are set so that only the owner can wake you in any group by default. Trigger phrases are defined in agents.list[main].groupChat.mentionPatterns. This applies to WhatsApp, Signal, Telegram, and other supported platforms.

---

Joining a Group

When the owner @mentions you in a group chat, follow these steps in order.

Step 1 — Capture context

From the inbound message metadata: platform (e.g. whatsapp, signal), group ID (the chat_id / from field), and duration (parse from the owner's message — default 30 minutes if unspecified).

Step 2 — Open the gate

Patch channels.<platform>.groups.<group_id>.requireMention to false in openclaw.json. The gateway file-watches the config and hot-reloads automatically — no restart needed.

Step 2b — Open the sender filter ⚠️ Critical — easy to miss

groupAllowFrom controls not just who can wake you in a group, but also which senders' messages are delivered to you once active. If it's set to only the owner's number (the default), messages from other group members will be silently dropped even with requireMention: false.

Fix: patch channels.<platform>.groupAllowFrom to ["*"] so all group members' messages are delivered.

This is safe because groupPolicy: "allowlist" still restricts which groups you are active in — opening the sender filter only affects groups you've explicitly joined.

Verify with openclaw doctor — config changes must pass schema validation.

Step 3 — Signal before going quiet

Before doing any work (research, lookups, etc.) triggered by a group message, send a brief acknowledgment first: "On it, give me a moment 👁️" — then go do the work. Silence looks like a crash.

Step 4 — Introduce yourself

Say hi, introduce yourself briefly if it's a new group. Participate like a human — use judgment about when to contribute. Do not respond to every message.

Step 5 — Set a closing cron job

Create a one-shot cron job (kind: "at") for the parsed duration. When it fires: patch requireMention back to true for this group in openclaw.json, then send a brief goodbye. The gateway hot-reloads and the gate closes — no owner action needed.

Step 6 — Confirm to owner

Tell the owner the window is open and when it closes: "Joined! I'll be here for 60 minutes — going quiet at 4:19 PM."

---

Behavior While Active

• One response per message — don't triple-tap with different reactions
• Signal before working — acknowledge first, deliver second (see Step 3)
• Don't dominate — respond when you add value; stay quiet for casual banter between humans
• Be present, not performative — contribute naturally, like a human participant

---

Leaving a Group

Timed close (automatic): When the closing cron fires: patch requireMention: true back for this group in openclaw.json, send a brief goodbye to the group. Gateway hot-reloads.

Early close (owner request): Owner says @<agent> that's enough / close → patch requireMention: true immediately, cancel the cron, say goodbye.

Extend (owner request): Owner says @<agent> stay for another X mins → cancel existing cron, set a new one.

---

Troubleshooting

Messages from group members not reaching me: Check groupAllowFrom — if it's restricted to the owner's number, non-owner messages are silently filtered. Set to ["*"] (see Step 2b).

"thinking/redacted_thinking blocks cannot be modified" errors: This happens when the session has reasoning tokens in its history and a subsequent API call tries to re-process them. Fix: clear the session transcript file (find it via sessions.json in the agent sessions directory). The session will restart clean on the next message.

---

Notes

• Group ID is in inbound message metadata (chat_id / from field)
• Config changes hot-reload — no gateway restart or Docker restart needed
• When closing, set requireMention: true for the specific group entry (or remove it to fall back to the wildcard default)
• groupAllowFrom: ["*"] combined with groupPolicy: "allowlist" is the correct secure pattern — open sender filter, restricted group allowlist