/lhm-bigdata-workflow-migration-skill

name: lhm-sch-workflowmigration
description: |
  User-facing entry Skill for LHM schedule migration (workflow migration). Provides three capabilities:
  (1) Query skill capabilities — output the skill introduction document;
  (2) Create data source — recognize "建数据源/创建数据源" (create data source) instructions and route to lhm-sch-ds
  to complete data source creation, name validation, metadata upload, and connectivity testing;
  (3) Schedule migration — complete a migration instruction end-to-end: config validation → environment
  initialization (lhm-sch-env) → data source existence check (lhm-sch-ds) → workflow exploration & conversion
  (lhm-sch-read-exec) → deployment & upload to DataWorks (lhm-sch-deploy).

  Triggers: asking what this skill can do / introducing capabilities; instructions such as
  "建数据源 / 创建（新增、添加）一个 XX 类型的数据源" (create a data source of type XX);
  or migration instructions such as "把 <源数据源> 迁移到 <目标数据源>" (migrate <source> to <target>),
  in natural language or the -source/-tag/-exStr/-dir parameter form, as well as any request mentioning
  migrating scheduler systems such as DolphinScheduler / Airflow to DataWorks.

  Do not trigger for: SQL conversion (sql-trans), DDL migration (ddl-trans), data validation (DataCheck),
  or other non-schedule-migration tasks.

LHM Schedule Migration User Entry

This Skill is the **user-facing master Playbook**. It does not call APIs directly; it recognizes user intent, routes to the execution sub-skills under the `skill` directory, and handles state hand-off between stages and communication with the user.

> 🧭 **STEP 0 — Mandatory Scope Classification Gate (run this BEFORE any tool call, any todo/plan item, and any environment setup).** Read the user's message once and freeze the scope using the "Capability Selection Rule" below. State the decision explicitly to yourself before doing anything else, e.g. *"Scope: Capability 2 only — the migration mention is generic (no data source name), so Capability 3 is NOT actionable."* This classification is the very first step of the run; nothing — not the plugin gate, not `setup_session.sh`, not a todo list — happens before it. > > **Hard gate — Capability 3 (schedule migration) is actionable ONLY if the message names at least one concrete data source** ("migrate X to Y", "migrate X", or the `-source X` / `-tag Y` parameter form). When Capability 3 is **not** actionable, you MUST NOT, at any point in the whole run: > - create any Capability 3 / migration todo, plan item, or "remaining migration work" tracker; > - run `setup_session.sh` in the stage-less (`all`) form, or install `lhm-sch-read-exec` / `lhm-sch-deploy` — a data-source-only run uses `--stage ds` (see Capability 2); > - ask for, mention, or collect source/target data source names, SQL dialect conversion expressions, or config-file paths; > - bundle migration parameters into the same clarification question as data-source parameters; > - append any "to continue with the (scheduled task) migration, I still need …" trailer, offer a fillable migration config template, or list exploration/conversion/deployment as pending work in the final message. > > A generic migration mention — e.g. "perform scheduled task migration in this lakehouse migration", "help me with the workflow migration" — is **background context, never a task and never a parameter-collection target**. Treating it as actionable is the single most common defect in this playbook and is exactly what causes the run to fail to terminate after a successful data-source creation. Once the scope is frozen here it must never be widened afterwards.

> ⛔ **Plugin prerequisite — hard stop (mirrors the LHM dispatcher's Step 2.1 Hard Stop Gate)**: every execution sub-skill below (`lhm-sch-ds`, `lhm-sch-env`, `lhm-sch-read-exec`, `lhm-sch-deploy`) reaches the service through `aliyun lhm <command>`, which requires the `aliyun-cli-lhm` plugin (>= 0.1.1, i.e. `~/.aliyun/plugins/aliyun-cli-lhm/manifest.json` must exist). Verify it before anything else; when this Skill is entered directly rather than through the dispatcher, run the dispatcher's `scripts/install_lhm_plugin.sh` and treat a non-zero exit as fatal. > > If the plugin is unavailable, **stop immediately**: report the environment error verbatim and terminate. Do **not** ask the user for the data source name, type, or any other business parameter; do **not** run `uv tool install`, `lhm-sch-ds`, or any other command in this playbook; do **not** fabricate a result. A CLI that installs successfully still cannot reach the service — it shells out to `aliyun lhm` through its `aliyun_cli.py` layer — so a successful install is never proof that the flow can proceed.

Path Convention (SKILL_HOME)

`SKILL_HOME` is the absolute path of the directory containing this SKILL.md. Determine it before executing any command:

# SKILL_HOME = <absolute path of the directory containing this SKILL.md>
echo $SKILL_HOME  # confirm the path is correct before any command

• Every path of the form `skill/...` in this file is relative to `${SKILL_HOME}`; expand it to `${SKILL_HOME}/skill/...` before execution. Never rely on the current working directory (pwd).
• The sub-skills under `skill` are **not registered as invokable skills** by the discovery mechanism; load them by file path only, and when delegating to a sub-agent, pass the fully resolved absolute paths.

It provides three capabilities:

| Capability | Trigger | Action | |------------|---------|--------| | Capability 1: Query skill capabilities | User asks "what can this skill do / introduce its capabilities" | Output the content of [docs/introduction.md](docs/introduction.md) | | Capability 2: Create data source | Instructions to create a data source (see trigger phrases below; the Chinese trigger phrases are declared in the frontmatter description) | Route to [skill/lhm-sch-ds/SKILL.md](skill/lhm-sch-ds/SKILL.md) to complete data source creation | | Capability 3: Schedule migration