huawei-cloud-terraform-generator git:20261107.eabf2bcA

Immutable. This exact content never changes and is served at /api/v1/blob/f408660d466afab7.

---
name: huawei-cloud-terraform-generator
description: Generate Huawei Cloud Terraform configurations and execute deployment with user-guided approval. Use this skill when users want to create Huawei Cloud infrastructure as Terraform, whether they ask explicitly for Terraform or describe goals such as deploying a website, launching an application, or creating network, compute, database, load balancing, or storage resources. Trigger when users mention 创建/create、生成/generate、部署/deploy、配置/configure、使用/use、管理/manage、华为云/Huawei Cloud、Terraform、ECS、VPC、资源/resource、云服务器/ECS、虚拟机/VM、实例/instance、网络/network、负载均衡/ELB、数据库/database、RDS、存储/storage、OBS、桶/bucket、域名/domain、DNS、证书/certificate、SSL、监控/monitoring、日志/log、备份/backup、容器/container、CCE、函数工作流/FunctionGraph
---

# Huawei Cloud Terraform Generator

## 1. Overview

This skill turns user infrastructure goals into Terraform configurations for Huawei Cloud. The primary workflow is to:

1. understand the user's actual deployment intent
2. determine which resources should be created
3. determine whether existing resources should be reused
4. confirm key specifications and dependencies
5. **verify every resource specification against the target region's available resources — query first, write later**
6. ensure Terraform is installed
7. generate Terraform configuration files
8. run validation steps and fix generation issues until `terraform plan` succeeds
9. ask user for confirmation and execute `terraform apply` if approved

This skill provides an interactive workflow where the agent guides the user through credential configuration, validates the plan, and executes apply upon explicit user confirmation.

## 2. Prerequisites

Before using this skill, ensure the following are available:

1. **Terraform** — installed in PATH or auto-installable (see validation-workflow.md)
2. **Provider download source** — the Huawei Cloud mirror should be reachable (see validation-workflow.md)
3. **Target region** — the deployment region (e.g. cn-north-4, cn-south-1) must be identified
4. **Windows long-path support (Windows only)** — this skill ships a deep `reference/**` + `assets/**` tree, and `git clone` on Windows can abort with `Filename too long` and leave an **incomplete work tree**. Before cloning on Windows:
   - prefer a short clone root (e.g. `D:\hw-skills`) instead of a deeply nested project directory;
   - or enable long paths for that single command: `git clone -c core.longpaths=true https://gitcode.com/developer-skill/huaweicloud-skills.git`;
   - if an existing clone already has an incomplete work tree, repair it in place: `git config core.longpaths true && git checkout -f`.
   Linux/macOS need no special handling for these paths.

## 3. Parameter Confirmation

Before generating Terraform, propose a concrete resource plan for the user to confirm. The plan should include:

- recommended resource specifications
- available candidate options when applicable
- whether to create new resources or reuse existing ones
- pricing information only when obtained from a reliable source

See `reference/guardrails.md` for rules about not fabricating specifications and prices.

Do not ask the user to provide every parameter manually. Instead:

1. infer the likely architecture from the user's goal
2. propose a concrete plan with recommended defaults
3. confirm only the small number of decisions that materially affect correctness, cost, or architecture

Users should mainly confirm a proposed solution, not build the full parameter set themselves.

## 4. Workflow

This skill works in nine phases:

### 4.0 Credential handling (MUST READ)                                                                                                                                                                                                                                           

AK/SK credentials are read from environment variables `HW_ACCESS_KEY` and `HW_SECRET_KEY` (plus `HW_SECURITY_TOKEN` or `HUAWEICLOUD_SECURITY_TOKEN` for temporary/STS). They authenticate the **Terraform provider only** — they are NOT written into the FunctionGraph function `user_data`, which holds only a pre-created DevBridge API Key (see `reference/ecs-devbridge-option.md`).

Because the provider does not reliably resolve `security_token` from env vars, the agent **must** write it to `terraform.tfvars` as `security_token` when using temporary/STS credentials. AK/SK themselves may be passed via `TF_VAR_access_key` / `TF_VAR_secret_key`.

**DevBridge API Key handling:** the key MUST be pre-created in the sandbox before apply — reuse the sandbox key if valid, otherwise create one via DevStage API using the sandbox's user-level AK/SK (which DevStage accepts). Pass it as `devbridge_api_key`. The FunctionGraph function only forwards this key and never creates keys, so it carries no AK/SK.

Before any step that depends on credentials (resource queries, `terraform plan`, etc.), read the complete rules in `reference/guardrails.md`.
If an API or Terraform call fails with an authentication error: tell the user the specific error, ask them to confirm when the issue is resolved, then retry. Do not guide the user on how to configure credentials.

### 4.1 Understand the user's real goal

The user may describe a resource directly, such as creating an ECS instance, or describe a business goal, such as deploying a website or launching an application.  
You must first infer the intended Huawei Cloud architecture from the user's objective, not just from explicit resource names.

### 4.2 Determine the resource set

Based on the user's goal, identify:

- which resources need to be created
- which existing resources may be reused
- what dependencies exist between the resources

For example:

- a simple public website may require VPC, subnet, security group, ECS, and EIP
- a managed database deployment may require VPC, subnet, security group, and RDS
- a scalable public service may require VPC, subnet, security group, ECS or AS, ELB, and public access

### 4.3 Propose a resource plan for confirmation

**Pre-confirmation checklist (CRITICAL — MUST complete ALL items before proposing the plan when ECS is in the resource set):**

When the resource set includes ECS instances, the following checklist MUST be completed before proposing the resource plan to the user. Each item must be explicitly resolved — "skipped" is not a valid state.

- [ ] **DevBridge decision (4.3.1)**: Read `reference/ecs-devbridge-option.md` and ask the user whether to install DevBridge SSH tunnel. Record the answer (yes/no). This decision determines the security group configuration (see 4.3.2).
- [ ] **Security group ports (4.3.2)**: If DevBridge = yes → zero inbound rules, egress limited to TCP 443/80 + UDP 53. If DevBridge = no → ask user which ports to open.
- [ ] **Region confirmed**: User has confirmed or accepted the recommended region.
- [ ] **OS image confirmed**: User has confirmed or accepted the recommended OS image.

**Forbidden:**
- ❌ Proposing a resource plan without completing the pre-confirmation checklist when ECS is in the resource set
- ❌ Skipping the DevBridge question or assuming the answer
- ❌ Proceeding to 4.4 (resource availability verification) with unresolved checklist items

Before generating Terraform, propose a concrete resource plan for the user to confirm following the rules in the Parameter Confirmation section.

See `reference/guardrails.md` for rules about handling sensitive information.

### 4.3.1 ECS DevBridge SSH tunnel decision (CRITICAL — MUST ask before security group configuration)

**This step MUST be executed before 4.3.2 (security group rules).** The DevBridge decision determines the security group configuration:
- DevBridge = yes → zero inbound rules (SSH comes through tunnel, not public port), egress limited to TCP 443 + TCP 80 + UDP 53
- DevBridge = no → ask user which ports to open (4.3.2)

When creating ECS, check `reference/ecs-devbridge-option.md` for DevBridge SSH tunnel option. If the file exists, read it and follow its instructions (ask user, check conditions, generate with DevBridge, post-apply guidance, destroy cleanup).

**Forbidden:**
- ❌ Skipping this step and proceeding directly to security group configuration
- ❌ Assuming the user's DevBridge preference without asking
- ❌ Reading `reference/ecs-devbridge-option.md` but not asking the user

### 4.3.2 Confirm security group rules with user (CRITICAL)

**Prerequisite: 4.3.1 (DevBridge decision) must be completed first.** The security group configuration depends on the DevBridge decision:
- If DevBridge = yes: zero inbound rules, egress limited to TCP 443 + TCP 80 + UDP 53 (DevBridge tunnel connects out on TCP 443). Do NOT ask about inbound ports.
- If DevBridge = no: proceed with the normal port confirmation workflow below.

**Required workflow (when DevBridge = no):**

1. Infer likely ports from user's goal (Web server → 80, 443; SSH → 22; Database → 3306, 5432)
2. Ask user to confirm ports: "需要开放哪些端口？推荐：80、443、22"
3. Generate rules based on confirmed ports, NOT default rules

**Terraform generation:**
```hcl
# User confirmed: 80, 443, 22

resource "huaweicloud_networking_secgroup_rule" "http" {
  security_group_id = huaweicloud_networking_secgroup.main.id
  direction         = "ingress"
  ethertype         = "IPv4"
  port_range_min    = 80
  port_range_max    = 80
  protocol          = "tcp"
  remote_ip_prefix  = "0.0.0.0/0"
}

# ... similar for 443, 22 (always include ethertype = "IPv4")

# Always include egress
resource "huaweicloud_networking_secgroup_rule" "egress" {
  security_group_id = huaweicloud_networking_secgroup.main.id
  direction         = "egress"
  ethertype         = "IPv4"
  remote_ip_prefix  = "0.0.0.0/0"
}
```

**Forbidden:**
- ❌ Using only egress rule without ingress rules
- ❌ Using hardcoded default ports without asking user
- ❌ Generating rules that don't match user confirmation
- ❌ Configuring security group before completing the DevBridge decision (4.3.1)

### 4.4 Verify resource availability BEFORE generating any code

**This step is mandatory and must never be skipped. A failed query is not a license to proceed — it is a blocker that must be resolved.**

Before writing a single line of Terraform, you MUST verify every resource specification in the confirmed plan against the target region. The target region is already known from the confirmed plan in step 4.3 — lacking the region means step 4.3 was incomplete and must be revisited. There is no excuse for not knowing which region you are deploying to.

1. **Step 1 — Read the target skill's SKILL.md first (DO NOT skip):** You MUST read the file `../huawei-cloud-computing-query/SKILL.md` before invoking the skill. This tells you the exact invocation format, required parameters, parameter format, and how to pass the target region. You cannot correctly invoke a skill you haven't read.
2. **Step 2 — Invoke the skill with confirmed parameters:** Only after reading the skill definition, invoke the `huawei-cloud-computing-query` skill with the exact parameters it requires, passing the target region from the confirmed plan in step 4.3. Confirm that each resource specification in the confirmed plan actually exists and is available in the target region. Any specification that cannot be confirmed MUST NOT appear in any .tf file.
3. **Cross-region assumptions are forbidden** — a resource available in region A does NOT imply availability in region B. Always re-query for the target region.

**Forbidden:**
- ❌ Invoking the `huawei-cloud-computing-query` skill without first reading its SKILL.md
- ❌ Guessing or fabricating parameters for skill invocation
- ❌ Proceeding to generate Terraform when a resource specification cannot be confirmed available
- ❌ Assuming resource availability carries over across regions

**If the query fails (environment error, network issue, SDK crash):**

- You MUST NOT proceed to generate Terraform. Stop immediately.
- Diagnose and fix the issue: invoke the `huawei-cloud-computing-query` skill's environment check, verify credentials, check network.
- Retry the query. If it fails again, fix and retry again.
- There is no "graceful degradation" — an unverified specification is a broken deployment waiting to happen.
- The only acceptable outcomes from this step are: (a) all specs confirmed available, or (b) a spec is confirmed unavailable and the user is asked to choose a different one.

**Why this matters:** Writing an unavailable flavor into `main.tf` produces a configuration that passes `terraform validate` but fails at `terraform apply` — the worst kind of error because it surfaces only after minutes of waiting.

**When modifying existing Terraform** (user asks to change a flavor, switch regions, use a different instance type, etc.): re-run the availability query for the new specification in the new region BEFORE editing any .tf file. Do not assume the previously-queried results still apply.

### 4.5 Generate Terraform after confirmation

**Pre-generation validation (CRITICAL — MUST pass before writing any .tf file):**

If the resource plan includes ECS instances, verify:
- [ ] DevBridge decision was explicitly made (yes or no) in 4.3.1 — not skipped
- [ ] If DevBridge = yes: `reference/ecs-devbridge-option.md` was read and all conditions checked
- [ ] Security group rules match the DevBridge decision (DevBridge = yes → zero inbound; DevBridge = no → user-confirmed ports)

If any check fails, go back to 4.3 and complete the pre-confirmation checklist. Do NOT generate Terraform with unresolved decisions.

**CRITICAL: Before generating, MUST read relevant reference documents from Section 8.1 mapping table.**

Once the user confirms the resource plan, generate the Terraform files following the required structure and style rules.

See `reference/terraform-generation-guide.md` for detailed file structure and content rules.

**Critical:** Generate all required files (providers.tf, variables.tf, main.tf, terraform.tfvars, README.md) and verify they exist before proceeding.

### 4.6 Verify credentials configuration

Before proceeding to validation, verify that Huawei Cloud credentials are configured via environment variables.

See `reference/guardrails.md` for rules about AK/SK handling.

### 4.6.1 Configure Huawei Cloud mirror for provider download

**Before running terraform init, configure the Huawei Cloud mirror to avoid slow downloads from the official Terraform registry.**
**Do NOT attempt to download from official registry first. Always use Huawei Cloud mirror.**

**Steps:**
1. Check if local provider cache exists (see validation-workflow.md for locations)
2. If cache exists and version >= 1.90.0, skip download
3. If download needed, create `.tfrc` file in the project directory:
   ```hcl
   provider_installation {
     network_mirror {
       url = "https://mirrors.huaweicloud.com/terraform/"
       include = ["registry.terraform.io/huaweicloud/*"]
     }
     direct {
       include = ["registry.terraform.io/hashicorp/*"]
     }
   }
   ```
4. Set `TF_CLI_CONFIG_FILE` environment variable to the `.tfrc` file path
5. **Every `terraform init` command MUST include `TF_CLI_CONFIG_FILE` in the same command line. Bare `terraform init` without the env var is FORBIDDEN.** Example:
   ```bash
   export TF_CLI_CONFIG_FILE="/path/to/project/.tfrc" && terraform init -upgrade
   ```

### 4.7 Validate and fix the generated configuration

Run validation in order: `terraform fmt -recursive` → `terraform init` → `terraform validate` → `terraform plan`

If any step fails, inspect the error, fix the configuration, and retry until `terraform plan` succeeds.

See `reference/validation-workflow.md` for detailed validation steps.

### 4.8 Display cost estimation (CRITICAL — MUST NOT SKIP)

**This step is MANDATORY and MUST be executed immediately after `terraform plan` succeeds, BEFORE any confirmation dialog or `terraform apply`. Skipping this step is a CRITICAL violation.**

**Cost display format (fill with actual resources from the plan):**
```
💰 费用预估

即将创建的资源：
- [资源类型] ([规格]): [预估费用]
- [资源类型] ([规格]): [预估费用]
- ...

预估合计: [总费用]

📌 华为云价格计算器: https://www.huaweicloud.com/pricing.html#/calculator
```

**Required elements (ALL must be present):**
- Resource list with specifications (from confirmed plan)
- Estimated monthly cost per resource (range is acceptable)
- Total estimated cost
- Link to Huawei Cloud pricing calculator (fixed URL)

**If you cannot estimate a cost:** still list the resource with "费用请参考价格计算器" — do NOT omit the resource from the list.

**Verification:** Before proceeding to step 4.9, confirm that you have output ALL required elements above. If any element is missing, stop and add it.

### 4.9 Execute terraform apply with user confirmation

After cost estimation is displayed, popup a confirmation dialog for user confirmation before executing apply.

See `reference/guardrails.md` for rules about user confirmation workflow.

### 4.10 Apply error repair loop

If `terraform apply` fails, inspect the error, fix the configuration, re-run `terraform plan`, and re-execute `terraform apply`. Repeat until successful.

### 4.11 Post-apply resource verification

After `terraform apply` succeeds, verify that deployed resources match the confirmed plan. If discrepancies found, report and fix them.

## 5. Guardrails

See `reference/guardrails.md` for detailed guardrail rules.

Key principles:
- Do not fabricate specifications, prices, or resource facts
- Execute terraform apply with explicit user confirmation
- Do not request sensitive information
- Do not invoke any referenced skill without first reading that skill's SKILL.md file

## 6. Terraform Generation Rules

After the user confirms the resource plan, generate Terraform that is minimal, valid, and aligned with the confirmed solution.

See `reference/terraform-generation-guide.md` for detailed guidance on file structure, content rules, data source usage, and variable design.

Core principles:
1. Start from the confirmed resource plan
2. Follow the Minimum Viable Configuration principle
3. Prefer Terraform validity over unnecessary flexibility
4. Use existing package references when relevant

## 7. Environment Preparation and Validation

See `reference/validation-workflow.md` for detailed guidance on ensuring Terraform availability, provider download **(from Huawei Cloud mirror)**, validation order, authentication, and repair loop.

## 8. Reference Usage and Template Guidance

Use the reference materials, templates, examples, and helper utilities in the skill package when relevant.

### 8.1 Use existing references when relevant

**MUST consult these references before generating:**

| Resource | Reference Document | Key Pattern |
|----------|-------------------|-------------|
| **通用规则** | `reference/guardrails.md` + `reference/terraform-generation-guide.md` | 密码自动生成、不向用户要敏感信息 |
| Security Group | `reference/VPC-best-practices/VPC-best-practices.md` → "Deploy Security Group" | `ethertype` is required |
| ECS with EIP | `reference/ECS-best-practices/Deploy-Instance-with-EIP-best-practices.md` | Use `huaweicloud_compute_eip_associate`, `public_ip = .address` |
| **ECS with DevBridge** | `reference/ECS-best-practices/Deploy-Instance-with-DevBridge-best-practices.md` | user_data + zero ingress SG + EIP for outbound + DevBridge auto-setup |
| VPC/Subnet | `reference/VPC-best-practices/VPC-best-practices.md` → "Deploy Basic Network" | VPC/subnet structure |
| RDS | `reference/RDS-best-practices/RDS-best-practices.md` | Database + network config |

### 8.2 Use existing examples and templates as a starting point

If the package contains an example close to the target scenario, use it as a starting point. Preserve useful structure, adapt to the confirmed plan, and remove unneeded resources.

### 8.3 Match user goals to relevant references

Map business goals to service references (e.g., "deploy a website" → VPC + ECS + EIP, "managed database" → RDS + network).

### 8.4 Use references to improve, not to overbuild

Keep the final Terraform aligned with the user-confirmed plan and follow Minimum Viable Configuration principle.

### 8.5 Do not rely on templates blindly

Always verify that the template matches the confirmed plan and validate through the normal validation workflow.

### 8.6 Packaging and publishing size limits

`assets/**` is a library of ready-to-use templates and accounts for most of the files in this skill package; `SKILL.md` + `reference/**` are the rules and must always ship. If the channel used to publish the skill enforces a file-count or archive-size ceiling, publish `SKILL.md` + `reference/**` only, exclude `assets/**`, and tell the user which templates were left out instead of silently dropping them.

The duplicated `assets/rds/reference/**` copy (88 documents that already exist under `reference/**`) has been removed — shipping the same reference documents twice inflated both the file count and the archive size, and its deepest paths were the ones that broke Windows `git clone`. Do not re-introduce copies of `reference/**` inside `assets/**`.

## 9. Quality Checklist

Before finalizing, ensure:

- [ ] The generated Terraform matches the confirmed resource plan
- [ ] All 5 required files were generated and verified (providers.tf, variables.tf, main.tf, terraform.tfvars, README.md)
- [ ] No sensitive information was requested from user
- [ ] Validation reached `terraform plan`, or the blocker was clearly explained
- [ ] Cost estimation was displayed BEFORE user confirmation (step 4.8 — MUST NOT skip)
- [ ] Cost estimation includes ALL required elements: resource list, specifications, estimated cost per resource, total cost, pricing calculator link
- [ ] User was asked for confirmation via confirmation dialog before terraform apply
- [ ] `terraform apply` was executed only after explicit user confirmation (or user declined)
- [ ] If ECS is in the plan: DevBridge decision was explicitly asked and recorded (yes/no) in 4.3.1