Use this Skill for Alibaba Cloud Lindorm work: instance lifecycle and configuration, networking and access control, monitoring, performance, storage, connection diagnosis, backup, migration, permissions (including Lindorm SQL user management with CREATE USER and GRANT), slow queries, SQL development, and Search, vector, graph, AI, multimodal, or knowledge-base workflows. Trigger on Lindorm product or CLI terms such as LindormTable, LindormTSDB, LindormSearch, Lindorm AI, HBase/AliHBase, lindormcli, Lindorm CLI, aliyun lindorm, or Chinese requests mentioning 宽表引擎、时序引擎、搜索引擎、向量检索、图引擎、白名单、实例创建/扩缩容/释放. Use this Skill's references or official Alibaba Cloud documentation; do not invent Lindorm-specific facts from general training knowledge.
When CLI invocation is required, the Agent must verify:
CLI installed: aliyun version >= 3.4.1 — the aliyun lindorm subcommand is only available from 3.4.1 onwards. On an older CLI every aliyun lindorm ... call fails as an unknown command, so check the version before assuming a command is broken. If the CLI is missing or too old, see references/03-ref/cli-installation-guide.md. The lindorm plugin itself is pulled in by the AI-Mode step below (aliyun configure set --auto-plugin-install true + aliyun plugin update); confirm with aliyun lindorm --version.
Credentials configured:
Security Rules:
NEVER read, echo, or print AK/SK values
NEVER ask the user to input AK/SK directly in the conversation or command line
ONLY use aliyun configure list to check credential status
If no valid profile exists, STOP. Configure credentials outside of this session.
[MUST] Permission Failure Handling: When any command or API call fails due to permission errors at any point during execution, follow this process:
Read references/03-ref/ram-policies.md to get the full list of permissions required by this SKILL
If ram-permission-diagnose skill is available, use it to guide the user through requesting permissions. Otherwise, directly output the required RAM policy/action list, the error code, and step-by-step instructions for the user to request permissions from their administrator via RAM Console
Pause and wait until the user confirms that the required permissions have been granted
Observability (MUST follow for every aliyun command)
Upon loading this skill, generate a fresh random session ID (32-char lowercase hex string) once for the entire session, and use it as {session-id} below. The session ID MUST be newly generated for each session: do NOT reuse the example value below or any session ID from a previous session.
Read the skill version from the version field of references/manifest.json and use it as {skill-version} below.
Rule: Every aliyun CLI command that calls a cloud API MUST include the --user-agent flag.
Local utility commands (e.g. configure, plugin, version) do not support this flag and should be excluded.
Do not skip, alter the format, or omit --user-agent on any aliyun API command invocation.
Parameter Confirmation
Before executing any command, all user-configurable parameters (region, instance ID, time range, etc.) must be confirmed with the user.
Version Detection
For instance operations, the Agent must first determine the instance architecture, because V1 and V2 use different subcommands. Prefer aliyun lindorm instance list: it returns every instance in the region with both an arch (v1 / v2) and a service_type column, so one call resolves the architecture without guessing:
bash
aliyun lindorm instance list --lindorm-region cn-shanghai --output json
For a single known instance, aliyun lindorm v1 instance describe <id> also returns service_type for both architectures — the underlying GetLindormInstance action is shared, despite the v1 command path.
service_type maps to the architecture as follows:
service_type
Version
Deployment
lindorm
V1
Single-AZ
lindorm_multizone
V1
Multi-AZ (HA)
lindorm_multizone_basic
V1
Multi-AZ (Basic)
lindorm_v2
V2
Single-AZ
lindorm_v2_multizone
V2
Multi-AZ (Basic)
lindorm_v2_multizone_ha
V2
Multi-AZ (HA)
General Policies
Region Policy
Scenario
Command
Requires region
List supported regions
aliyun lindorm regions list
❌ Region-agnostic; falls back to a default endpoint when nothing is configured
Query all-region overview
aliyun lindorm summary
❌ Region-agnostic; covers V1 + V2 across every region
✅ --lindorm-region — the endpoint is resolved from the region, not from the instance ID
Cloud monitoring query
cms commands
❌ Not needed, region auto-resolved via instanceId
⚠️ [MUST] Under aliyun lindorm, pass the region as --lindorm-region, never --region.--region is a global flag of the parent aliyun CLI, which consumes it before the plugin ever sees it. The command still succeeds but queries the profile's region instead of the one you asked for — a wrong-answer trap, not an error. The plugin does emit a warning to stderr, which the Agent must not ignore:
text
note: using region cn-shenzhen (from profile/environment). '--region' is consumed by the aliyun CLI
and never reaches this plugin — use '--lindorm-region <region>' to override.
The same applies to --profile, whose plugin-side equivalent is --lindorm-profile. From aliyun lindorm --help:
text
--lindorm-region string Same as --region; use this under 'aliyun lindorm', where --region is consumed by the aliyun CLI
--lindorm-profile string Same as --profile; use this under 'aliyun lindorm', where --profile is consumed by the aliyun CLI
When no --lindorm-region is given the region comes from the active profile. Always pass --lindorm-region explicitly, and verify the region_id in the output before telling the user which region the results describe.
Exception: profile create --region <region> is a command-local flag of that subcommand and works as written.
When a user reports that a region-scoped query silently returned another region's data (no error, wrong region_id), diagnose it as this flag trap — never as a RAM/permissions (Forbidden) problem. State the root cause (--region is consumed by the parent CLI) and the fix (--lindorm-region).
⚠️ summary under-reports — do not use it as an inventory. Observed returning a self-consistent total while individual regions were undercounted or missing entirely (e.g. a region reported as 9 instances while instance list --lindorm-region for that region returned 11). Treat it as a fast overview only; for an accurate count, use regions list then instance list --lindorm-region <region> per region.
Time Format
Cloud Monitor time parameter timezone notes:
✅ 2026-04-14 08:00:00 (local time, parsed as CST Beijing time)
✅ 1773897600000 (Unix millisecond timestamp, no timezone ambiguity)
✅ 2026-04-14T08:00:00Z (ISO 8601 UTC full format, parsed as UTC, i.e. CST+8 = 16:00)
❌ 2026-04-14T08:00Z (ISO 8601 short format, no seconds — unsupported, returns parse param time error)
❌ Never use UTC Z format for user-intended local times (e.g. if user says "14:00", write 2026-04-14 14:00:00, not 2026-04-14T14:00:00Z)
⚠️ Note: local time and ISO 8601 Z format query different time windows — common source of timezone-related issues
Command Reference
Query (read-only, no billing impact)
Command
Description
Example
aliyun lindorm regions list
List supported regions (DescribeRegions); region-agnostic
aliyun lindorm instance ... is an alias of aliyun lindorm v2 instance ....
⚠️ Under aliyun lindorm, use --lindorm-region / --lindorm-profile, never --region /
--profile — the latter are global flags of the aliyun CLI, which parses them itself and does
not forward them to the plugin, so they are silently ignored (exit code 0, wrong region used).
The aliases work on the standalone binary too, so one spelling covers both modes.
Requires plugin v0.2.20+.
Other flags available on every subcommand: --aliyun-profile / --output table|json|yaml (-o) /
--yes / --non-interactive.
whitelist / security-group / switch-pay-type / engine-list exist identically under both
v1 instance and v2 instance; storage is architecture-specific — pointing v1 instance storage
at a V2 instance returns HTTP 200 with an empty body (not an error), and the reverse returns 451.
Enums for create / modify
Enum
Values
EngineType (--engine)
TABLE wide table / TSDB time series / LSEARCH search / LVECTOR vector / LTS stream / LCOLUMN column store
--engine format
<EngineType>:<NodeSpec>:<NodeCount>[:<DiskType>:<DiskSizeGB>], repeatable; the disk tail is for arch 3.0 only — on 1.0 / 2.0 prefer instance-level --cloud-storage-*
CloudStorageType
StandardStorage standard / PerformanceStorage performance / CapacityStorage capacity
ArchVersion
1.0 single-zone (--zone-id + --vswitch-id) / 2.0 multi-zone basic / 3.0 multi-zone high availability (2.0 and 3.0 both need --primary-* + --standby-* + --coordinator-*)
Full metric details: references/02-ops/monitoring-guide.md
Interaction Guidelines
Output Format
Monitoring Query:
text
[Summary] CPU usage 25% (normal)
[Time] <YYYY-MM-DD HH:MM–HH:MM>
[Trend] Stable (variance <10%)
[Details] avg 24.5%, max 32.1%, min 18.3%
Error Troubleshooting:
text
[Error Code] InvalidParameter.InstanceId
[Meaning] Instance ID is invalid or does not exist
[Possible Causes] 1.xxx 2.xxx 3.xxx
[Resolution Steps] 1.xxx 2.xxx 3.xxx
Instance List:
text
[Region] cn-shanghai [Count] 3
| ID | Name | Status | Engines |
|----|------|--------|---------|
| ld-xxx | prod | Running | LindormTable + LindormTSDB |
Answer Language and Terminology (MUST)
Chinese question → answer in Chinese. When the user asks in Chinese, the final answer must be in Chinese (never an all-English reply) and must reuse the user's standard Chinese terms verbatim at least once each — e.g. 云监控 (not only "CloudMonitor"), 全地域 (not only "cross-region"), 全量替换 (not only "full replacement"), 白名单 (not only "whitelist"/"IP whitelist"), 拓扑 (not only "topology"), 连接地址 (not only "connection address"/"endpoint"). Bilingual explanations are fine; an all-English answer or dropping the Chinese term entirely is a failed answer.
Name API response fields exactly. When explaining a query result or a mismatch, cite the exact response field name — e.g. region_id, ServiceType, net_type. Paraphrasing without the field name loses traceability.
Pair every control-plane OpenAPI operation with its CLI form. Any Lindorm control-plane OpenAPI operation mentioned in an answer — not only in blocked scenarios — must be given together with its corresponding aliyun lindorm CLI command (e.g. GetLindormInstance / aliyun lindorm v1 instance describe). This pairing rule does not apply to data-plane SQL, HBase Shell, Elasticsearch-compatible HTTP, or Gremlin operations that have no corresponding Lindorm control-plane OpenAPI operation.
Blocked Execution — Always Deliver the Complete Plan
When a query cannot complete (instance not visible under the current credentials, permission denied, resource not found, empty monitoring data, etc.), do not stop at reporting the blocker. The final answer MUST still deliver, in full:
The complete decision path — name the exact OpenAPI operation AND its CLI command (always paired, never only the CLI form) for every branch, not only the branch attempted. Example: storage analysis requires GetLindormInstance (aliyun lindorm v1 instance describe) → ServiceType first, then GetLindormV2StorageUsage (aliyun lindorm v2 instance storage) or GetLindormFsUsedDetail (aliyun lindorm v1 instance storage); connection diagnosis requires instance status via GetLindormInstance, engine endpoints via GetLindormInstanceEngineList (aliyun lindorm v1 instance engine-list / v2 instance engine-list), topology via GetLindormV2InstanceDetails (aliyun lindorm v2 instance describe, returning engines[] / node_groups[] / connect_address_list[]), and net_type (public vs VPC).
Every item the user asked for — if the user asked for instances and their engines, engines are covered explicitly; if asked to analyze peaks, the peak-analysis result or method is stated explicitly (in the user's own terms, e.g. 峰值).
Exactly what is missing to proceed — instance ID, owning account, region, time window.
The ready-to-run command(s) the user can execute once the missing input is provided.
Instantiated examples, never empty placeholders. Where a real value is unavailable (e.g. zero instances in the account), still show the deliverable's concrete shape: a topology table with its real columns, a full connection-address format with real ports (e.g. ld-xxx-proxy-lindorm.lindorm.rds.aliyuncs.com:30020, MySQL protocol 33060, TSDB HTTP 8242). A bare <待查询> / <TBD> placeholder without the instantiated format is a failed reply.
A reply that only explains why it is blocked is a failed reply.
Code Generation Standards
General Principles
Reference Skill documents first: Lindorm is domain-specific knowledge — information must come from references docs; direct answers from training knowledge are prohibited
Check official docs when Skill doesn't cover it: For scenarios not covered by references docs, consult official Alibaba Cloud documentation
