mo-shared

mocli - Mowen CLI shared rules

This skill is a prerequisite skill for the Mowen CLI skill library, guiding you on how to use mocli to complete configuration initialization, API Key configuration, parsing of interaction responses with mocli , display rules, and security rules.

Prerequisite references

General execution flow

First determine the specific mocli subcommand corresponding to the user's intent; do not use search-type commands in place of more precise list-type commands.
If a command requires a UID, and the user provides a person's name, nickname, or alias, prioritize using mo-remark to look up the UID; if there is no match, then use user search or ask the user to provide the UID.
After executing mocli , first read the top-level code、status、reason, and only after confirming success parse reply。
When displaying list-type results, prioritize using the ordered ID list in the reply (such as note_ids、uids、events); then retrieve details from the corresponding Map (such as notes、users), to avoid incorrect order caused by directly iterating over the Map.

Configuration initialization

For first-time use, the user needs to provide the Mowen API Key, and use mocli auth init --apik <api-key> to complete initialization.

API Key configuration and management

During use, if mocli responds with AUTH error (the user may have reset the API Key on the Mowen platform or the local configuration was lost), you can remind the user to provide the API Key again, and use mocli auth init --apik <api-key> [--force] to reinitialize or replace (--force) API Key。
You can use mocli auth info [--profile] to view the current configuration information, and use --profile to additionally obtain the Profile information on the Mowen platform for the account corresponding to the current API Key.

Response parsing rules

code=0 and status=OK indicate success; business data is usually in reply .
meta.alerts indicates an important notice, which may appear on success or failure; it should be prioritized, and the display position should be determined by the notice type, for example, a new CLI version reminder is usually attached after the business result.
status=FAIL or code!=0 indicates failure, and you should prioritize displaying the actionable suggestions in reason、msg and meta.hints .
reason=AUTH: Remind the user to provide the API Key again, and use mocli auth init --apik <api-key> --force to update the configuration; do not output the old API Key.
reason=VALIDATE: Indicates that the parameters are invalid, and provide optional corrections based on the parameter range of the current skill.
reason=NETWORK: Indicates a network or proxy failure; if executed in a restricted environment, you can indicate that network/proxy permissions are required.
reason=API and api_error.trace_idexists: display trace_id to facilitate reporting the issue, but do not leak authentication information.
If an empty list or empty Map is returned, clearly state "no data matching the conditions was found"; do not fabricate results.

Response display rules

General principle: according to the user's requirements, based on the amount of data in the data entries, display it to the user as clearly, explicitly, and beautifully formatted as possible

Detailed rules:

Avoid making the data dull; appropriately add some emoji to make the data more interesting
Format timestamps into readable time
Try to use emoji for Boolean values
If there is relatively little data, display the information to the user in as much detail as possible
If there is a lot of data, display it to the user as clearly, unambiguously, and with as much formatting polish as possible, using forms such as tables/lists. For selecting table fields:
- First, based on the user's requirements, select the fields the user cares about
- If the user has not specified fields, display the fields that most data entries have, maximize the use of display space, and at the same time try to avoid a column having only a few data entries
When displaying UserInfo.name , if the client supports Markdown or HTML links, and the same UserInfo 's home_url is non-empty, use that link to wrap the name (e.g., [name](home_url)); otherwise display only the name, and do not fabricate or output an empty link.
When displaying NoteInfo.title , if the client supports Markdown or HTML links, and the same NoteInfo 's url is non-empty, use that link to wrap the title (e.g., [title](url)); otherwise display it according to the original title rules, and do not fabricate or output an empty link.
If the above detailed rules are inconsistent with the user's requirements, the user's requirements shall prevail

Note list display suggestions:

When there is little data, display the core information item by item: time, author, note title, and summary. If the user cares about a certain field (such as read count, whether it is paid, or public status), prioritize adding that field.
When there is a lot of data, first give a brief overview (quantity, time range, main authors or topics), then list several of the most relevant or latest key notes; do not provide only a summary while omitting specific entries.
For note titles, prioritize using note.title. If the title itself does not contain 「」 or 『』, wrap it with 『』; for the author, prioritize using users[note.uid].name; for the summary, prioritize using note.brief。
When fields are missing, do not fabricate content. You may omit missing fields, or use clear placeholders such as "Untitled", "Unknown author", or "No summary".

Update reminder

When mocli detects that a new version of the CLI is available, it will return an update reminder via meta.alerts . This reminder is important information and should beclearly and explicitlyshown to the user, while avoiding repeated displays that cause disturbance.

When displaying the update reminder:

Keep key information such as the current version, latest version, build time, and update command.
You may use a prominent emoji + short textto indicate that this is a CLI update reminder, but do not rewrite or omit the specific update command.
If the same update reminder has already beenclearly and explicitlydisplayed in the current session (prioritize judging by current version + build time, and latest version + build time), it may still continue to be reminded in subsequent responses, but should bedownplayedto a brief footnote that does not occupy the main content area.
Do not automatically execute the update command unless the user explicitly requests an update.
If both business data and an update reminder exist in the response, first display the business result requested by the user, then append the update reminder.

Security rules

It is prohibited to output secrets(user_key, api_key) in plaintext to the terminal.
Before write/delete operations, the user's intent must be confirmed。