/alibabacloud-dts-job-manager

name: alibabacloud-dts-job-manager
description: Create, query, and manage database synchronization jobs in Alibaba Cloud Data Transmission Service (DTS), covering synchronization link creation, job status and progress visibility, job renaming, starting, suspending, or resuming jobs, and instance class and hourly price lookup. Use when the user mentions DTS, a DTS job/instance/link, data synchronization, or database synchronization; asks what synchronization jobs exist, how far a job has progressed, or what its incremental latency is; asks how much a synchronization costs, what the small instance class costs, or what unit it is billed by; needs full or incremental synchronization for a data migration or cross-region disaster recovery; or says “sync data from one database to another.” Supports database synchronization among RDS MySQL, PolarDB MySQL, and PolarDB-X 2.0; between RDS PostgreSQL and PolarDB PostgreSQL; and between ApsaraDB for MongoDB replica sets.

Alibaba Cloud DTS Job Manager

Core scope

Create and manage only same-account, one-way cloud-database synchronization jobs whose source and destination databases belong to the [supported synchronization links](references/supported-links.md#directed-link-groups). Apply the [source and destination database configuration](references/database-instance-configuration.md) for database instances or clusters, access methods, and regions; apply [DbList](references/db-list.md) and [Reserve](references/reserve.md) for synchronized objects and parameters.

Bidirectional or reverse synchronization, cross-account jobs, migration, subscription, data validation, and unregistered engines are outside management scope. Read-only queries may report these jobs, but stop before any write.

Runtime

Every operation runs through `dtscli`, which must be on `PATH`. macOS, Linux, and Windows are supported. When the shell reports `dtscli: command not found`, read [platform installation and command execution](references/runtime-platforms.md) to select the installer, paths, and shell syntax for the actual host. When the current message already authorizes installation, run the documented non-interactive installer and continue; only stop and tell the user when that authorization is absent. Never fall back to another way of calling DTS.

When a `dtscli` command fails because the Alibaba Cloud CLI or the DTS plugin is missing — including `Plugin 'aliyun-cli-dts' is required ... but not installed`, even when `error_class` is `remote` — run this once and then continue the same command. Do not ask the user to authorize it, and do not add `--update`:

dtscli job deps install --yes

That install is not a plan change. If `execute` failed with `resource_effect` `NONE` only because the component was missing, retry `execute` once on the same `attempt_id` under the approval already given.

Do not add `--update`, and do not run `aliyun` yourself: this includes plugin installation, version queries, and API calls for products such as DDS, MongoDB, or DTS. Do not replace the `aliyun` binary. Stop the current task only when a command's JSON output carries an `error_class` whose `message` contains `ERROR: unchecked version`: preserve and report that error, and run no further `dtscli job` command or any `aliyun` command. A successful `dtscli doctor` check that merely mentions those words is not that error; continue. When reporting the CLI version, quote the `version` field from `dtscli job deps install`. Do not run `aliyun version`. Do not upgrade the Alibaba Cloud CLI and do not read the same data through another interface. See [setup](references/setup.md#install-or-update-the-cli-and-plugin).

In the current user session, run `dtscli version --json` only the first time this Skill is used. Confirm that capabilities contains `skills.ensure`, then run:

dtscli skills ensure --agent <agent>

Later steps and sub-agents in the same session run business commands directly. Continue when `ready=true`, including `action=busy`. Stop and reload Skill files when `reload_required=true`. When `ready=false` without reload, read [automatic Skills updates](references/skills-updates.md). `--agent` names the current host's stable lowercase identifier and must match `[a-z][a-z0-9_-]{0,31}`. Common hosts: `codex`, `claude`, `cursor`, `zcode`, `qoder`, `qoderwork`, `qwencode`, `qwenworkcn`, `opencode`, `kimi`, or `pi`.

Results are written as JSON on standard output and progress on standard error. On failure, the exit code is non-zero. Standard output may contain a generic error with `error_class`, or retain the command-specific status or execution summary. Interpret the JSON under the relevant workflow; do not determine success from the exit code or one field alone.

Request identity

Before any cloud API invocation, read this skill's [package identity manifest](references/manifest.json). Use only its top-level non-empty string `name` as `{skill-name}` and only its top-level non-empty string `version` as `{skill-version}`. The `name` must match this Skill's frontmatter `name` and the skill directory name. If missing, invalid, or inconsistent, STOP. NEVER invent, guess, or reuse a name or version from another skill. On a skill switch or return, reread that skill's package identity manifest. Read [request identity](references/request-identity.md) before constructing the request identifier.

Before this skill's first cloud API invocation in a conversation, generate a fresh random 32-character lowercase hexadecimal session ID. Reuse that session ID for this skill throughout the conversation; each skill MUST use a distinct session ID. NEVER copy one from documentation, examples, another skill, or a previous conversation, and NEVER send the literal `{session-id}` placeholder.

Attach `--user-agent` only to `dtscli` commands that call an OpenAPI and accept it: `dtscli job instances`, `job price`, `job get`, `job list`, `job precheck`, `job start`, `job pause`, `job r