New chat-copilot skill: auto-digest, prioritize, and suggest replies for 99+ unread group messages

[webup]

Migrated from issue #112, originally opened by @AIwork4me. Moved to a discussion for broader design conversation.

Core pain point

Multiple executive customers report the same scenario every day:

Come back from a meeting, and WeChat / Feishu / DingTalk / WeCom have 99+ unread group messages, several of which @-mention me with action items. Skimming is exhausting, important information is drowned in noise, things that should have been answered weren't, things that should have been done get missed.

This is a daily, extremely high-frequency pain across essentially every knowledge worker:

• Too many groups, too many messages, the human brain can't process them.
• Important information (@-me, action items, decision asks) gets buried in noise.
• High reply pressure — every message needs reading plus reply composition.
• Particularly severe for executives — more managed groups, more cross-team groups, higher information density.

This issue proposes a skill, chat-copilot, that automatically reads group messages from multiple chat platforms, generates a structured digest, ranks priorities, suggests replies, and — after user confirmation — sends them with one click.

---

Design: the chat-copilot skill

Core flow

Scheduled fetch → smart digest + priority ranking → suggested replies → user confirms → auto-send

Per-platform feasibility

Platform	Read group messages	Send messages	Feasibility	Approach
Feishu	✅ im:message.group_msg reads all group messages	✅ POST /open-apis/im/v1/messages, 1000/min	High	Self-hosted bot + event subscription (HTTP/WebSocket)
DingTalk	⚠️ Only @-bot messages deliverable	✅ Bot group-send API	Medium	Stream-mode bot + @-bot trigger; limitation: cannot silently read all messages
WeCom	⚠️ Smart Bot (2026) can receive @-bot messages	✅ App message + appchat API	Medium	Smart bot + long-poll mode; limitation: still limited group-message ingest
WeChat (personal)	❌ No official API	❌ No official API	Low	Manual forwarding / screenshot → OCR parsing as a workaround

Priority strategy: Feishu first (most complete APIs) → DingTalk / WeCom next → WeChat via workaround.

Functional design

1. Scheduled message fetch

On the configured cadence (default every 30 min), automatically fetch:
- All new messages in joined groups (since last fetch)
- Messages that @-mention me (flagged separately)
- Messages containing action-item / decision keywords (auto-detected)
- DMs (optional)

Fetch strategy:

Platform	Mode	Notes
Feishu	Event subscription (WebSocket)	Real-time push, no polling
DingTalk	Stream mode + scheduled backfill	@-bot real-time + history backfill
WeCom	Smart-bot long connection	@-bot ingest + app-message read
WeChat	Manual trigger / forwarding bot	Forward group messages to the bot, or screenshot + OCR

2. Smart digest

Structure collected messages as:

📋 Group message daily — 2026-04-28 08:00

🔴 Urgent (3)
├─ [Product] @you Director Zhang needs Q2 roadmap by tomorrow → suggested: "Got it, will send Q2 roadmap draft this afternoon"
├─ [Customer] Customer reports prod bug affecting payment → suggested: "Received, investigating, ETA 1h to fix"
└─ [Ops] Server CPU alert, need to confirm scale-out plan → suggested: "Approve plan B, please proceed"

🟡 Important (5)
├─ [Design] Design spec updated, needs sign-off → suggested: "Approved, ready to hand off to dev"
├─ [Hiring] HR confirmed 3 candidates for interviews next week → suggested: "OK, Tuesday afternoon works"
└─ ...

🟢 Normal (12)
├─ [Casual] Non-work chatter...
└─ ...

📝 Action items (2)
1. Send Q2 roadmap to Director Zhang by tomorrow [due: tomorrow]
2. Confirm server scale-out plan [due: today]

Digest dimensions:

Dimension	Notes
Priority ranking	🔴 Urgent / 🟡 Important / 🟢 Normal, based on @-mentions, keywords, sender role
Group grouping	Messages from each group stay together
Action-item extraction	Auto-detects "please do X", "please confirm X"
Decision flagging	Highlights items that need the user to decide
Suggested replies	1–2 suggestions per message that needs a reply

3. Priority scoring

priority_score = w1 × is_mentioned
               + w2 × sender_authority  (org-hierarchy weight of sender)
               + w3 × urgency_keywords  (urgent / today / now / deadline …)
               + w4 × is_action_item    (contains todo / confirm / approve)
               + w5 × thread_replies    (discussion heat)
               + w6 × time_decay        (newer weighs more)

Weights are user-tunable.

4. Suggested reply generation

LLM-generated suggestions follow these principles:

• Concise and professional — default 1–2 sentences, no filler.
• Tone match — adjusts to group style (formal / informal) and sender relationship.
• Editable — users can modify before sending.
• Multi-option — offers 2–3 candidates.
• Style-learning — gradually learns the user's personal reply style from history.

5. Confirm & send

User flow:
1. Review digest → pick messages to reply to
2. Read suggestions → edit / pick / rewrite
3. Confirm → auto-send to the target group / DM
4. Mark processed → won't reappear in the next digest

Safety:

• Every reply must be user-confirmed; never auto-sent.
• Sensitive groups (customer-facing, executive) support "double confirm."
• Preview the final message before send.
• Support recall within the platform-allowed window.

---

Architecture

┌───────────────────────────────────────────────────────────────────┐
│                    chat-copilot skill                             │
├───────────────────────────────────────────────────────────────────┤
│                                                                   │
│  ┌──────────────┐    ┌──────────────┐    ┌───────────────────┐   │
│  │ Fetch engine │───→│ Digest engine│───→│ Reply suggester   │   │
│  │              │    │              │    │                   │   │
│  │ · scheduled  │    │ · dedup      │    │ · LLM reply gen   │   │
│  │ · event sub  │    │ · priority   │    │ · multi-option    │   │
│  │ · incremental│    │ · action ex. │    │ · style learn     │   │
│  │ · cache      │    │ · digest     │    │ · tone match      │   │
│  └──────┬───────┘    └──────────────┘    └───────┬───────────┘   │
│         │                                        │               │
│         │           ┌──────────────┐             │               │
│         │           │ Confirm &    │◄────────────┘               │
│         │           │ send engine  │                              │
│         │           │              │                              │
│         │           │ · confirm    │                              │
│         │           │ · safety     │                              │
│         │           │ · send       │                              │
│         │           │ · audit log  │                              │
│         │           └──────┬───────┘                              │
│         │                  │                                      │
├─────────┼──────────────────┼──────────────────────────────────────┤
│         │  Platform adapters (reuse channels module)              │
│         │                  │                                      │
│  ┌──────▼───────┐  ┌──────▼───────┐  ┌──────────┐  ┌────────┐   │
│  │ Feishu       │  │ DingTalk     │  │ WeCom    │  │ WeChat │   │
│  │ adapter      │  │ adapter      │  │ adapter  │  │ fallback│  │
│  │              │  │              │  │          │  │         │  │
│  │ im:message   │  │ Stream mode  │  │ Smart bot│  │ Manual /│  │
│  │ event sub    │  │ + bot API    │  │ long conn│  │ OCR     │  │
│  └──────────────┘  └──────────────┘  └──────────┘  └────────┘  │
├───────────────────────────────────────────────────────────────────┤
│  Storage (reuse PowerMem + local files)                          │
│  ~/.openclaw/chat-copilot/                                       │
│  ├── config.json          # platform config + group list + prefs │
│  ├── cache/               # message cache (dedup)                │
│  ├── digest-history/      # historical digests                   │
│  ├── reply-templates/     # user reply-style templates           │
│  └── sent-log.jsonl       # send log (audit trail)               │
└───────────────────────────────────────────────────────────────────┘

Coordination with the existing channels module:

The project's channels module already supports config management for 6+ platforms (Feishu, DingTalk, WeCom, etc. — appId / appSecret / credentials). chat-copilot reads those configs directly — no duplicate credential setup. The user configures credentials once in channels, and chat-copilot picks them up.

---

Directory layout

bundled-skills/chat-copilot/
├── SKILL.md                          # skill description and workflow guidance
├── _meta.json                        # metadata
├── references/
│   ├── platform-apis.md              # per-platform API endpoints & permissions
│   ├── priority-algorithm.md         # priority-ranking algorithm notes
│   └── reply-style-guide.md          # reply style templates & learning mechanism
└── scripts/
    ├── fetch-messages.mjs            # fetch messages (multi-platform)
    ├── generate-digest.mjs           # generate structured digest
    ├── prioritize.mjs                # priority ranking
    ├── suggest-replies.mjs           # generate suggested replies
    ├── confirm-send.mjs              # confirm and send
    ├── learn-style.mjs               # learn user reply style
    └── schedule-config.mjs           # schedule configuration

Frontend module (companion):

packages/web/src/modules/chat-copilot/
├── index.ts                          # ClawModule definition
├── ChatCopilotPage.tsx               # main page
├── components/
│   ├── MessageDigest.tsx             # digest view
│   ├── PriorityList.tsx              # priority list
│   ├── ReplyEditor.tsx               # suggested-reply editor
│   ├── ConfirmSendDialog.tsx         # confirm-send dialog
│   ├── DigestHistory.tsx             # historical digests
│   └── PlatformStatusCard.tsx        # per-platform connection status

---

SKILL.md sketch

---
name: chat-copilot
description: Group-message assistant. Use when the user needs help processing a flood of unread group chat messages — auto-digest, priority ranking, suggested replies, and confirmed sending. Works with Feishu, DingTalk, WeCom, and WeChat.
metadata:
  openclaw:
    requires:
      anyBins:
        - node
---

# chat-copilot

Use this skill when the user returns to a flood of unread messages
across Feishu, DingTalk, WeCom, or WeChat groups and needs help
processing them efficiently.

This skill reads messages from configured chat platforms, generates
a structured digest with priority ranking, suggests replies, and
sends them after user confirmation.

## Critical rule
- NEVER auto-send without explicit user confirmation
- ALWAYS show the final message content before sending
- Mark sensitive groups (customer-facing, executive) for double-confirm

## Commands
# Fetch new messages and generate a digest
node ${SKILL_DIR}/scripts/fetch-messages.mjs --platform feishu --since last

# Produce a prioritized digest
node ${SKILL_DIR}/scripts/generate-digest.mjs --summary --top 20

# Generate suggested replies for a message
node ${SKILL_DIR}/scripts/suggest-replies.mjs --message-id xxx --count 3

# Confirm and send a reply
node ${SKILL_DIR}/scripts/confirm-send.mjs --message-id xxx --reply "Confirmed, received" --platform feishu

# Learn user reply style
node ${SKILL_DIR}/scripts/learn-style.mjs --from-history

---

Example user config

{
  "platforms": {
    "feishu": {
      "appId": "cli_xxx",
      "appSecret": "***",
      "mode": "websocket",
      "groups": {
        "include": ["Product", "Customer", "Ops"],
        "exclude": ["Casual"]
      }
    },
    "dingtalk": {
      "clientId": "xxx",
      "clientSecret": "***",
      "mode": "stream",
      "groups": {
        "include": ["*"],
        "policy": "mentioned_only"
      }
    },
    "wecom": {
      "corpId": "xxx",
      "agentId": "xxx",
      "secret": "***"
    }
  },
  "schedule": "*/30 * * * *",
  "digest": {
    "maxItems": 50,
    "groupBy": "priority",
    "showReplies": true
  },
  "reply": {
    "autoSuggest": true,
    "style": "professional",
    "sensitiveGroups": ["Customer", "Executive"],
    "requireDoubleConfirm": true
  },
  "priorityWeights": {
    "isMentioned": 1.0,
    "senderAuthority": 0.7,
    "urgencyKeywords": 0.8,
    "isActionItem": 0.9,
    "threadReplies": 0.3,
    "timeDecay": 0.5
  }
}

---

Rollout plan

Phase 1 — Feishu MVP

• Scaffold chat-copilot skill directory and script framework.
• Feishu adapter: receive group messages via Event Subscription (WebSocket).
• Baseline message collection + dedup + incremental sync.
• Digest generation (by-group grouping + priority ranking).
• @-mention detection and action-item extraction.
• LLM-based suggested replies.
• Confirm-and-send flow (Feishu bot send).
• Basic frontend module (ChatCopilotPage + MessageDigest + ReplyEditor).

Phase 2 — DingTalk + WeCom + multi-group management

• DingTalk adapter: stream-mode bot + history backfill.
• WeCom adapter: smart-bot long connection + app-message read.
• Multi-platform aggregated view.
• Group filtering rules (include / exclude / policy).
• Reply-style learning from history.
• Frontend PlatformStatusCard + DigestHistory.

Phase 3 — WeChat workaround + smarter digest

• WeChat workaround: forwarding bot / screenshot OCR.
• User-adjustable priority weights.
• Multi-option replies (2–3 candidates).
• Auto daily/weekly reports (coordinated with clawprobe-cost-digest).
• Feishu card interactions (confirm / reject replies inline).
• Team collaboration: shared group-message handling across members.

---

Key design decisions

Why is "never auto-send" a core principle?

Executive customers have strong concerns about "AI replying for me":

• Sending wrong messages in customer groups can cause commercial damage.
• Misjudged tone in executive groups can trigger internal issues.
• Commitments / approvals require human judgment.

Therefore the core principle is: AI suggests, human decides, system executes.

Why reuse the channels module?

The project's channels module already handles platform config (credentials, policies, permissions). Reuse over rebuild:

• Credentials configured once in channels — chat-copilot picks them up.
• channels dmPolicy / groupPolicy naturally apply to message-collection scope.
• New platform adapters register in channels; chat-copilot supports them for free.

Why Feishu first?

Feishu has the most complete API:

• im:message.group_msg reads all group messages (not only @-bot).
• WebSocket long connection — no public IP required.
• 1000/min high rate limit.
• Clear enterprise permission / approval workflow.

---

Technical constraints (project conventions)

• Node.js v20+ only — no Python, Bun, or other runtimes.
• No native binary dependencies — pure JS.
• Follow the adapter pattern — each platform adapter returns AdapterResult<T>.
• Reuse channels module config — don't re-implement credential management.
• All user-visible text goes through i18n — zh.ts / en.ts / ja.ts.
• Collection scripts run via exec — same pattern as clawprobe-cost-digest.
• Message cache in local files — ~/.openclaw/chat-copilot/cache/.

---

Relation to existing issues / skills

Issue / skill	Relation
channels module	Reuses platform config & credentials; chat-copilot is a downstream consumer.
clawprobe-cost-digest	Digest generation can reuse its --summary mode; daily/weekly reports can coordinate.
content-draft	Reply-style learning can reuse its content-generation capability.
paddleocr-doc-parsing	WeChat screenshot OCR parsing can reuse it.
#49 LLM Wiki	Message digests can be persisted into the wiki as team knowledge.
#110 evolving-wiki	High-value group-message content can auto-persist into evolving-wiki.

---

Acceptance criteria

• bundled-skills/chat-copilot/ directory complete.
• Feishu adapter: WebSocket long connection reading group messages + bot send.
• Digest generation: by-group grouping + priority ranking (🔴 🟡 🟢) + action-item extraction.
• Suggested replies: LLM generates 1–3 candidates.
• Confirm-send: every reply must be user-confirmed; never auto-sent.
• Double-confirm for sensitive groups.
• Message dedup + incremental sync.
• Scheduled automated fetch (default every 30 min).
• Reuses the channels module for platform config.
• DingTalk adapter (stream-mode bot).
• WeCom adapter (smart bot).
• Reply-style learning.
• All scripts depend only on Node.js v20+.
• User-visible text is i18n-ed (zh / en / ja).
• Includes __tests__/ coverage.
• npm test passes locally.

---

Prior comments (from original issue)

@snakefood3232 (2026-04-28T10:44:57Z):

Handling the high volume of unread group messages is crucial to streamline workflow, especially when important information is buried in noise. I'd tackle this by developing a chat-copilot skill that integrates with Feishu first, using event subscriptions to fetch messages, summarize, prioritize, and suggest replies, before expanding to DingTalk and WeCom. I can have a prototype PR ready within 5 days. I've previously developed similar solutions for enterprise chat systems, ensuring robust integrations and effective user-driven automation.