Skip to content
Cloud & Infrastructure
Skill

/alibabacloud-cadt-deploy-on-aliyun

Build and deploy applications to Alibaba Cloud ECS — Local build + script injection + InstallApplication async deployment. Triggers: build, deploy, CI/CD, compile & package, publish to Alibaba Cloud, diagnose, troubleshoot, root cause, 502, 503, service not started, deployment

From plugin
alibabacloud-aiops-skills
213200 skills
Install
$ npx -y skills add aliyun/alibabacloud-aiops-skills --skill alibabacloud-cadt-deploy-on-aliyun --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/alibabacloud-cadt-deploy-on-aliyun

Context preview

The summary Claude sees to decide when to auto-load this skill.

Build and deploy applications to Alibaba Cloud ECS — Local build + script injection + InstallApplication async deployment. Triggers: build, deploy, CI/CD, compile & package, publish to Alibaba Cloud, diagnose, troubleshoot, root cause, 502, 503, service not started, deployment

SKILL.md

alibabacloud-cadt-deploy-on-aliyun.SKILL.md
name: alibabacloud-cadt-deploy-on-aliyun
description: >
  Build and deploy applications to Alibaba Cloud ECS — Local build + script injection + InstallApplication async deployment.
  Triggers: build, deploy, CI/CD, compile & package, publish to Alibaba Cloud, diagnose, troubleshoot, root cause, 502, 503, service not started, deployment failed.
license: Apache-2.0

Alibaba Cloud Application Build & Deploy

Standalone deployment Skill: **Build + Deploy** pipeline orchestration. User directly provides ECS instance IDs, region, and application information — no project/environment hierarchy dependency.

Workflow

Path A: Build + Deploy (new deployment)

[step-1] Session init + collect deployment info  ->  [step-2] Compile, package & upload  ->  [step-3] Application deploy + failure recovery + result output

Path B: Diagnose + Fix + Redeploy (troubleshoot previous deployment)

[step-1] Session init + detect diagnose intent  ->  [step-3] §3.0-D Run diagnostics + classify root cause  ->  ⛔ ASK-USER "fix and re-deploy?" (mandatory STOP)  ->  [step-2] Build fix (config/scripts only, NOT new source code)  ->  [step-3] G4 checklist + InstallApplication

> **Path B scope**: "Build" in Path B means applying the diagnosed fix to **existing deployment configuration** (e.g., `application.yml` port, JVM flags, start/stop scripts, env vars) and re-packaging — NOT writing new application source code from scratch. The application already exists on the ECS instance. > > **Path B re-deploy mandate**: After the user confirms [1] "fix and re-deploy", the **full pipeline** (step-2 build → G4 checklist → InstallApplication → wait_ready) is **always required** — even when the diagnosed fix is infrastructure-level (e.g., security group rules, DNS, firewall). The ASK-USER says "re-deploy", which means InstallApplication. Applying infra fixes manually and then testing with ad-hoc `curl` is NOT a substitute for the deployment pipeline.

| Step | Phase | File | |------|-------|------| | [step-1] | Session init + collect deployment info | CLI Bootstrap + PATH validation + cadt-deploy-on-aliyun -doctor + ASK-USER collect regionId/instanceIds/appName + **intent detection** | [steps/step-1-session-init.md](steps/step-1-session-init.md) | | [step-2] | Build | Local build + script injection + repackaging (output artifact file) | [steps/step-2-build.md](steps/step-2-build.md) | | [step-3] | Deploy + Output | **G4 install checklist (HITL, mandatory)** -> InstallApplication (async: `-run` + `-poll`) -> wait_ready -> **V18 post-deploy verification** -> root cause analysis -> result output | [steps/step-3-deploy.md](steps/step-3-deploy.md) |

> **Intent detection** (in [step-1]): If the user's request mentions "diagnose", "troubleshoot", "root cause", "502", "service not started", "deployment failed", or similar troubleshooting keywords — route to **Path B**. Otherwise route to **Path A**. See [step-1] §6 for the decision logic.

⛔ Pre-Deploy Hard Gates (MANDATORY — do NOT call InstallApplication without these)

Before calling `InstallApplication`, you MUST complete ALL of the following gates. Each gate is independently verifiable from the execution transcript. Skipping any gate is a **critical violation**.

| # | Gate | When | Evidence Required in Transcript | |---|------|------|-------------------------------| | **G0** | ASK-USER for `regionId` + `instanceIds` when not in initial request | [step-1] before §5.4 | Transcript MUST contain an explicit ASK-USER question for each missing field AND the user's response. Auto-discovery from CLI config, API enumeration, or env vars is a **critical violation** (see [step-1] §5.1–5.2). | | **G0a** | `cadt-deploy-on-aliyun -doctor` run and passed | [step-1] §5 before §5 (Collect Deployment Info) | Transcript MUST contain `cadt-deploy-on-aliyun -doctor` invocation with `all_ok: true` result. `doctor.json` MUST be persisted. Skipping entirely is a **critical violation** (see [step-1] §5). | | **G1** | `COPYFILE_DISABLE=1` on ALL `tar -czf` commands | [step-2] packaging | Every `tar` command in transcript MUST have `COPYFILE_DISABLE=1` prefix (required on ALL platforms — no-op on Linux, prevents AppleDouble on macOS) | | **G2** | G4 Install Checklist presented + user confirmed `[1]` | [step-3] before InstallApplication | `decisions.json` with `userResponse: "1"` + `userResponseAt` timestamp. Agent text output alone is NOT sufficient. | | **G3** | wait_ready loop executed after `-poll SUCCESS` | [step-3] after InstallApplication | Transcript MUST contain `[wait_ready] T0:` and `[wait_ready] probe:` markers. Ad-hoc `curl` or `ps aux` calls are NOT acceptable substitutes. | | **G4** | ECS instance info queried via skill CLI only | [step-1] §5.4 | Transcript MUST contain `cadt-deploy-on-aliyun -run EcsGetDesc` or `EcsGetDescList`. Direct `aliyun ecs describe-instances` calls are a **critical violation** — no exceptions, even when CLI bootstrap failed (fix it first). |

Gate Details

**G0 — ASK-USER for regionId + instanceIds (mandatory when not in initial request)**

# CORRECT — user explicitly provided region and instance in their request
User: "Deploy to cn-beijing, instance i-bp1xxx"

# CORRECT — agent asks user when info is missing
Agent: "请提供部署目标的地域 (regionId),例如 cn-hangzhou, cn-beijing"
User: "cn-hangzhou"
Agent: "请提供目标 ECS 实例 ID (instanceId)"
User: "i-bp1ai3ai0rpvx965zpw0"

# WRONG — agent auto-discovers region from CLI config (critical violation)
Agent runs: aliyun configure list → reads "cn-hangzhou" → proceeds without asking

# WRONG — agent auto-selects instance from API enumeration (critical violation)
Agent runs: aliyun ecs describe-instances → finds "order-api-ecs" → selects it without asking

**G0a — `-doctor` check (mandatory before collecting deployment info)**

# CORRECT — doctor run and evidence persisted
DOCTOR_RESULT=$(cadt-deploy-on-aliyun -doctor)
echo "$DOCTOR_RESULT" | jq .
# → all_ok: true, then persist to doctor.js
Read more
Ships withalibabacloud-aiops-skills

Official Alibaba Cloud Agent Skills collection, providing AI agents with rich Alibaba Cloud product capabilities and general-purpose tooling.

Get the whole plugin

Other skills on alibabacloud-aiops-skills.