/alibabacloud-cms-manage

name: alibabacloud-cms-manage
description: |
  Entry skill for the aliyun CLI distribution of CloudMonitor (CMS).
  Use when the user mentions aliyun cms2, CloudMonitor, CMS commands,
  or any CMS module operation such as Integration Policy/Center, APM, RUM,
  Prometheus Service, Recording rule, alert rule, alert template, alert history,
  event hub, SLS event, PromQL, cloud resource, service observability,
  monitoring onboarding, metric query, etc.
license: Apache-2.0
compatibility: aliyun-cli>=3.3.15
metadata:
  domain: aiops
  owner: cms
  contact: cms@alibaba-inc.com

CMS CLI — `aliyun cms2`

Prerequisite Check

1. **Check `aliyun` exists** — `which aliyun` (macOS/Linux) or `where aliyun` (Windows).

• Not found → ask the user to install the aliyun CLI first: <https://help.aliyun.com/document_detail/121541.html>. Stop and wait.

2. **Check CLI version** — run `aliyun version`. Minimum required: **3.3.15** (see `compatibility` in frontmatter).

> ⚠️ Compare version segments as **integers** (semver): 3.3.4 < 3.3.15 because 4 < 15. > Shell verification: `printf '%s\n' "3.3.15" "$(aliyun version)" | sort -V | head -1` > If the output equals the current version, the requirement is NOT met.

• Version OK → go to step 3.
• Version too old or unrecognized →

1. Run `aliyun upgrade --help` to test whether the `upgrade` subcommand exists.

• Available → run `aliyun upgrade -y` to update to the latest version automatically, then re-check `aliyun version`.

2. If `upgrade` not available → ask the user to upgrade manually following the official guide: <https://help.aliyun.com/zh/cli/update-cli>. Wait for the user to confirm the upgrade is complete, then re-check `aliyun version`. 3. If upgrade succeeded → go to step 3. 4. If upgrade failed → ask the user to upgrade manually: <https://help.aliyun.com/zh/cli/update-cli>. Stop and exit.

3. **Check `cms2` plugin** — run `aliyun cms2 --help`.

• Help output OK → continue to **Credentials**.
• `unknown command` / missing → **stop immediately**, output the error report below (append CLI version, OS, and error message), and make **no further CLI calls**.

---

Credentials

`aliyun cms2` reuses the aliyun CLI credential system (`aliyun configure`). Use `--profile <name>` to switch profiles.

Observability

Upon loading this skill, generate a random session ID (32-char lowercase hex string) once per session...

For every aliyun cms2 command, append: --user-agent "AlibabaCloud-Agent-Skills/alibabacloud-cms-manage/{session-id}"

Global Conventions

**Hard constraint**: fallback to `aliyun cms`, other API versions, or any workaround is strictly prohibited.

> **Run `aliyun cms2 <command> [subcommand] --help` before first use of a subcommand in a session** to get the full flag list and examples. Once the help for the same subcommand has been read in the current session and the command shape has not changed, reuse that knowledge instead of repeating the help call.

• **Prefer `-o text`** (default) to reduce token consumption for list/get; use `-o json` only when indented JSON is needed.
• **Before onboarding concrete resource IDs**, verify them with `entity query --source CloudResource`; do not rely on ID shape alone.
• **`entity query` default time range**: when the user does not specify `--from`/`--to`, default to the last 7 days (`--from` = now − 7d, `--to` = now, both as Unix seconds).
• **CloudResource queries default to all regions**: for `entity query --source CloudResource`, do not derive regions from workspace, policy, CLI defaults, prior commands, or existing policy regions. If the user does not explicitly limit the query to cloud resources in specific regions, omit the region parameter so cloud resources from all regions are queried. Only add a region parameter when the user explicitly provides a region constraint. State the final region coverage in the response.
• **Structured choice presentation**: when the active runtime exposes a structured user-input tool (for example `request_user_input`, select, form, or equivalent), use it for mutually exclusive user choices such as addon selection, workspace selection, resource scope mode, metric candidate selection, and yes/no confirmations. Keep each option decision-useful: concise label plus one sentence describing impact or tradeoff. If the structured tool is unavailable, supports too few choices, or is not callable in the current mode, fall back to a numbered plain-text list and ask the user to reply with the number or exact name. Never claim a select/form was shown unless the tool call actually succeeded.
• **Human confirmation required for writes and high-impact creates**: before any command that creates or changes cloud-side state (`create`, `update`, `delete`, `patch`, `start`, `stop`, etc.), show a concise confirmation summary and the exact command, ask whether the user confirms execution, and wait for a clear affirmative answer. The summary must include the operation, target resource identifiers, expected impact, and notable risks or irreversible effects when applicable. Do not require an exact phrase or long confirmation text; a clear affirmative answer such as "yes", "confirm", "proceed", or "确认" is sufficient approval. Skip confirmation only for dry-run, preview-only, or read-equivalent creates with no cloud-side impact; if uncertain, require confirmation.
• **Uncertain parameters must be explicitly answered by the user**: for any parameter whose value is not explicitly provided or cannot be reliably determined (e.g. `region`/`regionId`, workspace, policy, `resourceGroup`, tag, resource scope, `addonName`, resource type, cloud product/service name, onboarding configuration options, etc.), ask the user for a clear answer before proceeding. The exception is `entity query --source CloudResource` region handling: when the user does not explicitly limit the query to specific regions, omit the region parameter