/lhm-sch-ds

name: lhm-sch-ds
description: |
  Agent Playbook for LHM schedule data source management.
  Guides the user through data source creation, validation, OSS file upload, and connectivity testing.

  Triggers: create a data source, add a data source, validate a data source name, upload a metadata
  file, test connectivity, or any request related to LHM schedule data source management.

  Do not trigger for: schedule migration tasks, SQL conversion, DDL translation, or other
  non-data-source-management tasks.

LHM Schedule Data Source CLI & Agent Playbook

This Skill is **Agent-driven**. The `lhm-sch-ds` CLI exposes **stateless single-step commands**: each command makes **exactly one** API call, prints structured JSON status, and exits. There are **no loops inside** — the **Agent** is responsible for orchestrating step order, asking the user for decisions, and performing the OSS file upload (via curl). State (parsed configuration, data source name, new ID) is passed explicitly via command-line arguments; the CLI itself persists nothing.

Scope and Termination (Mandatory)

This skill covers **data source management only** — querying existing data sources, name validation, metadata upload, creation, and connectivity testing. It never plans, executes, or collects parameters for the schedule migration chain (exploration / conversion / deployment).

• **Terminal states**: `create` succeeded; or the user-requested `test-conn` finished; or an existing data source was selected in Step 4. At a terminal state, report the result and **stop**.
• **Never solicit migration parameters.** Do not ask for a source/target data source name, a SQL dialect conversion expression, or a migration config file path — not as a question, not as a "to continue with the migration ..." trailer on the final message, not as a suggested next step, and not as a fillable template.
• **Never report migration work as pending.** Lines such as "exploration / conversion / deployment not executed" are outside this skill's scope and must not appear in its output.
• **Resumption is the caller's decision, not this skill's.** When reached from the schedule-migration entry playbook, only that playbook decides whether a migration flow resumes — and it does so solely under the narrow exception in its Capability Selection Rule (migration already running, names already extracted, "data source does not exist" reported). A generic mention of migration in the original user request is not a reason to resume one.
• **Session stage**: a data-source-only run prepares its session with `setup_session.sh --stage ds`, which does **not** require the migration source/target data source names. Their absence is expected — never treat it as a blocker, and never turn it into a question for the user.
• **One question, one concern.** A clarification question asked by this skill may only concern data source parameters.

CLI Usage

Environment Prerequisites

**The environment and credentials have already been prepared by [lhm-sch-env](../lhm-sch-env/SKILL.md) at session start; this skill performs no environment validation whatsoever.** Simply run the business commands — do not run validation scripts, do not run `validate`, and do not re-confirm credentials or prompt the user about configuration.

> ⛔ **The one exception — the `aliyun-cli-lhm` plugin (hard stop)**: every command below reaches the service through `aliyun lhm <command>`, so the plugin (>= 0.1.1, i.e. `~/.aliyun/plugins/aliyun-cli-lhm/manifest.json` exists) must be present. If it is not, **stop before Step 0**: report the environment error verbatim and terminate. > > In particular, do **not** ask the user for `dsName`, `dsType`, or any other business parameter. The clarification rules further below are mandatory **only once the plugin is confirmed available** — while it is missing, every `check` / `check-name` / `create` / `test-conn` call is guaranteed to fail, so an answer collected now can never be used. Do **not** run `uv tool install` or `lhm-sch-ds` either: this CLI shells out to `aliyun lhm`, so a successful install is never proof that the flow can proceed.

Only when a command actually reports an environment-class error (e.g., credentials not found, command not found) should it be handed to [lhm-sch-env](../lhm-sch-env/SKILL.md); when relaying its guidance, **never write secrets on behalf of the user, and never echo secret values**.

Command Invocation

All commands are executed via `lhm-sch-ds <command>`.

Status Code & Exit Code Contract

Each single-step command outputs a JSON object with a `status` field to **stdout** and exits with an exit code; the Agent branches on them:

| `status` | Exit code | Meaning | Agent action | |----------|-----------|---------|--------------| | `ok` | `0` | Operation succeeded | Use the payload and proceed to the next step | | `empty` | `0` | `check` — no same-name data source found | Continue with `check-name` → `create` | | `match` | `0` | `check` — one or more existing data sources found | Show `matches` to the user and ask which one to use | | `available` | `0` | `check-name` — the name is available | Continue with upload/create | | `exists` | `2` | `check-name` — the name is taken or invalid | Have the user provide a new name and rerun `check-name` | | `failed` | `2` | Unrecoverable business/API error | Report `err_message` and abort | | *(config error)* | `1` | Missing credentials / invalid config file | Fix the environment and retry |

Commands

Single-Step Data Source Commands

# 1. Query whether a same-name data source already exists (ListMetaDataComponentPage)
#    --ds-type may be omitted: when omitted, dsType is sent as an empty string "" (no type filtering)
lhm-sch-ds check --ds-name <DS_NAME> [--ds-type <DS_TYPE>] [--category-type WORKFLOW]

# 2. Validate name uniqueness before creation (ExecMetaDataComponentName)
lhm-sch-ds check-name --ds-name <DS_NAME>

# 3. Upload a local metadata file to OSS — o