WeCom Message Push

Problem

In terminal-based agent environments such as Claude Code, engineers often need to push build results, release status, or alerts to WeCom without manually logging into the admin console, copying user IDs, or scattering corporate credentials across project directories. wecom-send-message addresses a narrow, practical problem: expose common WeCom API actions as Agent-callable commands, including user lookup, message sending, group-send preview, and audit logs.

How It Works

The skill drives a local Python tool, wecom_client.py, to call the WeCom API. During setup, it first runs check, then guides you to configure corp-id, agent-id, and secret, and finally uses verify to confirm connectivity. Credentials are kept in a skill-private directory by default, reducing the risk of reading the wrong .env file from the current workspace.

The normal workflow usually looks like this:
- Find recipients: supports search-name, search-mobile, and search-email; user-info can inspect user details.
- Send messages: supports send-text, send-markdown, and send-card; card messages can include a jump link.
- Handle group sends: dept-list and dept-users help identify the target scope; multiple recipients are separated by |, while @all requires a preview first and an explicit --yes confirmation before sending.
- Track delivery: real sends are appended to .state/message_audit.json, and history can list recent records.

Boundaries and Caveats

It is suitable for trusted terminal workflows where WeCom notifications are needed, but it is not a replacement for a formal messaging platform. You need valid WeCom app credentials, appropriate app visibility, contact permissions, and network access to the WeCom API. Error codes such as 60020, 60011, or 40014 usually point to invisible recipients, missing contact permissions, or expired access tokens. Be careful with group sends and @all: the default preview is not a confirmation to send, and explicit confirmation is required before the message goes out.