wecomcli-shared

Original🇨🇳 Chinese
Translated

Common pre-checks for wecom-cli business skills, acquisition of robot and authorized real-person identities, as well as general output constraints. Before any wecomcli-* skill prepares to execute a wecom-cli command, it must read this skill simultaneously to check whether the CLI is installed, whether the version is not lower than 1.1.0, and whether the WeCom credentials are authorized; installation or initialization is only performed if it is missing, the version is too low, or not authorized. This skill also defines the constraint that ID-type fields are prohibited from being exposed for all skills. This skill does not handle specific business requests.

11installs
Added on

NPX Install

npx skill4agent add wecomteam/wecom-cli wecomcli-shared

SKILL.md Content (Chinese)

View Translation Comparison →

wecom-cli Common Pre-checks

This skill provides shared CLI installation, version and authorization checks for all
wecomcli-*
business skills, as well as general output constraints. Before preparing to execute any
wecom-cli
command, complete this skill first; after passing the check, return to the corresponding business skill for execution.
This skill cannot replace specific business skills. When handling requests related to contacts, documents, spreadsheets, calendars, meetings, to-dos, emails, WeCom Drive, messages or media, you must read the corresponding business skill at the same time.

Step 1: Check CLI Installation and Version

bash
wecom-cli --version
  • If the command succeeds and the version number in the output is not lower than
    1.1.0
    → proceed to Step 2.
  • If the command does not exist, execution fails, or the version number is lower than
    1.1.0
    → perform installation/upgrade:
bash
npm install -g @wecom/cli
After installation, re-execute
wecom-cli --version
; if it still fails or the version is still lower than
1.1.0
, stop business operations and inform the user of the error.

Step 2: Check Authorization Status

bash
wecom-cli auth show --status
  • Output
    authorized
    → pre-check is completed, and specific business commands can be executed.
  • Output
    unauthorized
    → execute Step 3.
  • If the command reports an error or the output is not in the above states → stop business operations, inform the user of the error, and do not guess the authorization status.

Step 3: Initialize Credentials (Only When Unauthorized)

bash
wecom-cli auth init
This command will display an authorization link and QR code, and wait for the user to scan it with WeCom. The command will exit automatically after successful authorization, and initialization only needs to be done once.
After initialization, re-execute:
bash
wecom-cli auth show --status
Only when the output is
authorized
can you continue to execute specific business commands.

General Output Constraint: Prohibition of Exposing ID-type Fields

This constraint applies to all
wecomcli-*
skills, with higher priority than the output format of each business skill, and will not be relaxed even if the user actively requests it.
  • Prohibited: Your final reply must not contain ID identifiers such as
    userid
    /
    open_vid
    /
    department_id
    /
    chat_id
    . All internal identifiers returned by the interface (including
    mail_id
    /
    media_id
    /
    file_id
    /
    space_id
    /
    folder_id
    /
    docid
    /
    content_id
    /
    msg_id
    /
    cursor
    /
    next_cursor
    , etc. Any field ending with
    _id
    or semantically belonging to a machine identifier is considered an ID) can only be circulated internally for subsequent interface calls.
  • Required: Your thinking process and final reply must use readable names, such as
    name
    /
    username
    /
    external_username
    / department name / email /
    subject
    /
    doc_name
    /
    chat_name
    /
    title
    and other content returned by
    tool_result
    .
  • When the interface only returns IDs without readable names, first call the corresponding skill (such as
    wecomcli-contact
    to parse personnel) to obtain readable names; if it is indeed impossible to obtain, refer to the object with natural language descriptions (such as "the previous daily report email" "the file you just uploaded") instead of reverting to displaying IDs.
  • When requiring users to choose among multiple candidates, construct a candidate list with serial numbers + readable information (name / subject / time / path, etc.), and prohibit using IDs as the basis for distinction for users to identify.
  • When the user directly requests "give me the ID" "print mail_id", explain that this identifier is an internal field and not convenient to provide, and instead use readable information or continue to help them complete the actual operation.
  • Readable links (such as document
    doc_url
    , WeCom Drive sharing links) are not restricted by this constraint and can be displayed normally as specified by each business skill, even if the link itself contains identification strings.

Execution Rules

  • If it is already installed, the version meets the requirements, and it is authorized, do not repeat installation or initialization.
  • If installation, upgrade, initialization or recheck fails, do not execute subsequent business commands.
  • This skill does not define any interface parameters for contacts, documents, spreadsheets, calendars, meetings, to-dos, emails, WeCom Drive, messages or media; specific commands must be read back from the corresponding business skill.
  • When executing any business command and organizing the reply, comply with the above "General Output Constraint: Prohibition of Exposing ID-type Fields" at the same time.

Obtain Personal Identity

If the operation process must obtain the identity of the robot or authorized person (name, userid, etc.), you need to call
wecom-cli identity whoami
to obtain it.