/alibabacloud-maxcompute-cli

name: alibabacloud-maxcompute-cli
description: >
  Use this Skill for operational MaxCompute or ODPS data-plane work and
  concrete static diagnosis. MUST invoke it even without a CLI mention, with
  an exact command plan, or when diagnosis or clarification forbids execution.
  Also use for any `aliyun maxc` command or a concrete MaxCompute/`aliyun maxc`
  JSON envelope supplied for diagnosis. Covers SQL/query/cost/explain,
  metadata/partitions, sample/profile/transfer, jobs,
  authentication/permissions/sessions, namespaces, quotas, connectivity, and
  errors. Exclude CLI/SDK/PyODPS development, pricing/docs-only, DataWorks
  scheduling, product/tool/architecture comparison or selection, requests
  confined to other SQL engines, and adjacent cloud resources. Triggers:
  "operate or diagnose a concrete MaxCompute or aliyun maxc data-plane task"

Alibaba Cloud MaxCompute CLI

Use `aliyun maxc` for MaxCompute. Use Alibaba Cloud CLI to manage MaxCompute with the configured invocation. In the public-cloud distribution, `aliyun maxc` is the MaxCompute data-plane command for metadata, SQL, jobs, permissions, and data transfer. Run commands through the configured invocation: `aliyun maxc ...`.

Completion contract

Before the first command, turn every explicitly requested command, check, and reported field into a private checklist. Each named action is a separate required step: one command's output or an inference never substitutes for a different command the user named. For example, “inspect the schema and find the latest partition” requires both `meta describe` and `meta latest-partition` before the dependent sample, profile, query, or download. Complete every allowed planned step in the requested order without omission. Run a step only once unless the user's exact plan requires a retry or the bounded retry rules below permit one, and stop dependent steps after a failed gate. Before the final answer, compare that checklist with the actual command trace. If an allowed requested step is missing and all of its gates succeeded, run that step; do not add work outside the user's plan. Cost and explain requests must use the identical SQL, and neither one substitutes for the other or authorizes a normal query. The final answer is part of the task. State the result directly in the response even when a detailed artifact was written. Include every identifier, error code, command/check name, and result field the user asked to see, together with its observed value or failure state. Never replace the result with a generic readiness message or only an artifact path. In particular:

• for clarification-only requests, the chat response itself (not only a file)

must list the five missing items and literally contain every label in the required-literals block below; stop there without an execution handoff. The required literal groups are declared in the frontmatter description. Preserve those exact user-language labels when the matching request requires them.

• for a named authentication inspection, identify each completed check, such

as `--oauth`, `agent context`, `auth whoami`, and `session show`;

• for `agent context --json`, report the observed `version`, `auth_status`,

`backend_reachable`, and every requested capability field in the final answer. Start the answer with one plain-text line exactly of the form `version=<value>; auth_status=<value>; backend_reachable=<value>;` before any table or heading, even when values are incomplete, null, or false. Do not replace the context values with a generic readiness claim.

• for a missing-partition envelope, retain `error.code`, table, partition

column, required `--partition`, and the conditional partition-discovery command such as `meta latest-partition`;

• for a download, state the verified partition, `output_path`, and

`rows_written` only from successful envelopes and the resulting local file.

• for sample/profile, state the successful `data.sample` and `data.profile`

envelopes and include the literal fields `sampled_rows` and `null_count_in_sample`; if either command failed, state that failure rather than inventing a value.

• for a CSV/TSV upload dry-run, preserve the exact local file path and include

the literal fields `rows_found` and `rows_written`, explicitly stating that the literal token `--dry-run` did not write data; report them only from the successful upload envelope. Put the path, both field names, and the literal `--dry-run` token in the final answer itself, not only in a command or artifact.

• for any supplied MaxCompute JSON/error envelope, preserve the literal

`request_id` (or its observed value) in the final diagnosis alongside the error code; never omit it when giving recovery advice.

• for a mixed read/write SQL safety check, name every supplied target table

(for example `audit_log`) in the final chat response, not only in an artifact, and retain the supplied `SELECT`, `DROP`, `--force`, `project`, and `schema` tokens when explaining why execution is rejected. For the fixture `SELECT COUNT(*) FROM audit_log; DROP TABLE audit_log;`, begin the response by naming the supplied target `audit_log` before any artifact summary. For an explicit allowed command plan, begin with the first allowed command and execute the plan before writing artifacts or a final summary; a planned command is not evidence that it ran. Use the user's language in the final answer. Preserve every requested command, field, subsystem name, and literal spelling or case that a check may depend on; do not translate or title-case tokens such as `cache`, `semantic`, `auth whoami`, or `auth can-i`. When the user names the required recovery terms, include their exact literals from the required-literals block.

User-specified command plan takes precedence

An explicit command plan in the user's request is authoritative. If the user says “only run” or “do not run any other command”, run exactly the listed commands in the l