WeCom Material Archiver

Problem

Enterprise WeCom groups often accumulate files in chat streams without a clear archive boundary: who uploaded them, whether the expected count is complete, when the batch should close, and which task owns each file are all ambiguous. @user_cfe24d7e/wecom-image-archiver turns archiving into a stateful group task instead of a one-off bot response.

How It Works

The skill treats folder-name category-tag @MaterialArchiver as the single entry point. After triggering, the parser extracts fields by priority: @bot, quantity semantics, category tag, and folder name. If a category tag looks numeric, it is treated as expected_count. Tasks are isolated by group_id + user_id, and a group allows only one active task to prevent concurrent creation and mixed file ownership. Creation uses an atomic lock: check the active task, reject if present, create if absent. Once files are bound to the task, the state machine moves from CREATED to COLLECTING; after 2 minutes it can switch to WAIT_CHECK, and after 10 minutes it force-closes. In WAIT_CHECK, the bot offers “keep waiting” or “archive now” based on whether expected_count exists, with a 60-second debounce to reduce repeated prompts. On close, it notifies the user with file count and a status of success, partial completion, or manual termination. If a category exists, it writes an index under ARCHIVE_ROOT/_index/category-tag/; otherwise it skips indexing.

Limits

This skill fits WeCom groups where file collection has a clear closing condition, such as batch archiving or count-checked material submission. Permission is layered: all members can trigger archiving, upload files, and query status; changing save paths, timing parameters, and system configuration requires admin rights. Files sent before an archiving command are treated as orphan files, prompt the user to send @MaterialArchiver, and do not create a task. General conversation is limited to usage and format help, and process control does not accept free-form natural language instructions.