/lhm-sch-env

name: lhm-sch-env
description: |
  Environment and session preparation skill for LHM schedule migration (non-interactive execution stage). It does three things:
  (1) Install the lhm-sch-* CLIs as needed; (2) read the **already filled-in** user configuration
  (business fields must come from the config file; credentials are NOT collected here), validate it, and
  transcribe it into a temporary session config file that subsequent sub-skills load directly;
  (3) run environment checks (network connectivity / resource group status / Agent online status).

  Triggers: validate and transcribe migration configuration, prepare the schedule migration session
  environment, check LHM API connectivity / DataWorks resource group / service agent status,
  a credential error surfacing from the aliyun CLI default credential chain, lhm-sch-ds /
  lhm-sch-read-exec / lhm-sch-deploy command not found, install or uninstall the lhm schedule migration
  CLIs, confirm whether the current target is staging or production, clean up the session config after
  migration ends.

  Do not trigger for: guiding the user to fill in the configuration template (handled by the upper-level
  entry flow); and concrete migration business operations (creating data sources, exploring/converting
  workflows, deployment & upload), which are handled by lhm-sch-ds, lhm-sch-read-exec, and
  lhm-sch-deploy respectively.

LHM Schedule Migration Environment and Session Preparation

The four stages of schedule migration (data source preparation → exploration → conversion → deployment) share the same environment. This skill is the **only** place that handles environment preparation and the session config (credentials themselves are resolved by the aliyun CLI default credential chain):

User-filled lhm_credentials.json ─→ Validation (business fields required) ─→ Session config (temp directory) ─→ Environment check (full) ─→ Sub-skills load it directly

**Responsibility boundaries**:

• This skill is responsible for: **the `aliyun-cli-lhm` plugin pre-gate (see below)**, installing CLIs, validating existing configuration, transcribing the session config, environment checks (connectivity / resource group / Agent), and session cleanup. **It contains no user interaction whatsoever**.
• The upper-level flow (main process) is responsible for: delivering the template to the user, explaining the fields, waiting for the user to fill them in, and handling the blockers reported by this skill.
• The three execution sub-skills: **perform no environment validation at all** and execute business commands directly; their CLIs load the session config automatically. The single exception is the plugin pre-gate, which they must honour as a hard stop rather than re-validate themselves.
• The session config only needs to be prepared once; unless the user changes the configuration or the credentials expire, re-transcription is unnecessary. However, **the CLIs must be reinstalled every time** (see "CLI Installation Strategy" below).

> **⚠️ CLI Installation Strategy (must be followed)** > > All `lhm-sch-*` CLIs (including this skill's own `lhm-sch-env`) are installed via `uv tool install` as > **non-editable** packages — they cannot detect whether the source code has changed. Therefore, **every > time this skill is invoked, all CLIs required by the current stage must be reinstalled unconditionally** > before running `setup_session.sh`. > > **⚠️ Serial Execution Required (No Parallelism)**: The CLI installation scripts **must be executed serially — one at a time, in any order**. They **cannot be run in parallel or concurrently**. Each `install.sh` script must fully complete before the next one begins. There is **no required ordering** among the scripts; they may be executed in any sequence, but never simultaneously. This prevents race conditions and resource conflicts during package installation.

Execution

> ⛔ **Plugin pre-gate — runs before Step 0 (mirrors the LHM dispatcher's Step 2.1 Hard Stop Gate)** > > Every `lhm-sch-*` CLI reaches the service through `aliyun lhm <command>`, which requires the > `aliyun-cli-lhm` plugin (>= 0.1.1). Confirm that `~/.aliyun/plugins/aliyun-cli-lhm/manifest.json` > exists **before** reinstalling any CLI. If it is missing, run the dispatcher's > `scripts/install_lhm_plugin.sh` once and treat a non-zero exit as fatal: report the environment error > verbatim — including its printed installation instructions — and stop. > > On such a failure do **not** proceed to Step 0. Reinstalling the CLIs cannot repair a missing plugin: > they all shell out to `aliyun lhm` and would fail at the first call, so a successful `uv tool install` > is never evidence that the environment is usable. Equally, do **not** ask the user for the source/target > data source name or any other business parameter while the plugin is unavailable — collecting an answer > that cannot be used only wastes a round trip.

**Every invocation must follow this order** (the plugin pre-gate and Step 0 must not be skipped):

# ── Step 0: unconditionally reinstall all CLIs required by the current stage (mandatory every time) ──
# stage all (default): install all four CLIs
(cd skill/lhm-sch-env      && bash install.sh)
(cd skill/lhm-sch-ds       && bash install.sh)
(cd skill/lhm-sch-read-exec && bash install.sh)
(cd skill/lhm-sch-deploy   && bash install.sh)

# If only a specific stage is needed, install only the CLIs it uses:
#   --stage ds        → only lhm-sch-env + lhm-sch-ds
#   --stage read-exec → only lhm-sch-env + lhm-sch-read-exec
#   --stage deploy    → only lhm-sch-env + lhm-sch-deploy
#
# ⚠️ --stage also decides which business fields are mandatory:
#   --stage ds  → migration source/target data source names are NOT required (a data-source-only
#                 session never runs the migration chain, so demanding them would falsely report
#                 "session not ready" and push the caller into asking the user for unrelated
#